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ABSTRACT 


The Indian software industry is one of the best performing industries in India. The 
Fortune 500 companies prefer to outsource their software requirements to India. 
Despite such superlative performances, we have little global market share in software. 

This is attributed to Indian software efforts being primarily of the software services 
generally involving coding services. There is a global trend towards software 
products and packages. A Department of Electronics committee recommends that 
developing Indian made software products and packages will enable the industry to 
meet targets for the next five year plan. We have well-developed organizations to 
provide software services. Changing to a software product based strategy will involve 
changes in the organization. This thesis attempts to formulate a way to transition from 
current orientations to the required product orientations through observing the 
organization different software firms. This kind of approach, focusing on the 
organizational attributes of a software company have not been found in the available 
literature. The meager literature available, has treated project or teams' organization, 
not company organization. 

The broad research objectives aim to determine if we can understand and explain the 
management of a software service firm using the service literature. It also aimed to find 
how a product firm differed from a service firm in terms of organization. Not much is 
available on managing software companies. Most of the current business is of the kind 
called “professional consultancy” and "software services". Thus it was postulated that 
the service management literature would provide us with a means to understand the 



organization in a service firm. We observed the product firms to gain an understanding 
of the organizational peculiarities for product development. 

The study encompassed 7 companies in different cities in India. AH of these companies 
are among the best in their sectors of Indian software industry. Half of these were 
service companies and half were product development companies. One company was 
into both businesses. The data was collected through non-scheduled, semi-structured 
interviews. 

The findings of the study show that viewing the software services firm as a service 
business can indeed help understand and better manage it. It was found that software 
service firms do show characteristics of a service business. The product companies 
demonstrate a more stable and functionally oriented organization, particularly an 
independent, distinct testing group. It was found that a feedback process plays an 
important role in the development of the product. Product companies showed end-user 
domain expertize. 

Following are some suggestions. Service companies can adopt the service strategies of 
focus on niches and employ continuos learning policies. This will enable them to 
gradually develop domain expertize by accumulating experience in the end-user 
segment. They should encourage the same team to stay in one end-user segment and 
let that team develop domain expertise and the peculiarities of software development in 
that domain. Service firms should arrange to encourage specialization in competencies 
like requirements' generation and testing. 
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Chapter One 

1. Introduction 

1. 1 Sunrise industry: Software 

“And no matter where you are located in the food chain of Information 
Technology, everyone is developing expertise in software” — (Yoffie, 

1994) 

“What do the following have .in common: Commuters on the London 
Underground; customers of Citibank, American Express, Deutsche Bank; 
manufacturers GE, IBM, Reebok, and GM; and the passengers on Swissair, 
American Airlines, and Singapore airlines? They all depend on computer software 
developed in India ” — (BusinessWorld, 1995 ). 

Thus have many an article in recent times begun, focusing on the Indian software 
industry. If there has been a lot of attention on the Indian software, it is because 
software itself has been in the limelight in recent years. All of us are by now quite 
familiar with the words ‘Microsoft’, ‘DOS’, ‘Web’, ‘Netscape’, etc. Information 
technologies are touted as the harbingers of the information age by authors like Alvin 
Toffler, Naisbitt, among others. Software is the soul of these technologies. 

There are very few areas of production, engineering, education or general services that 
do not include software as an important and increasing complex component. 
Embedded software is at the core of the machine tool industries, vehicle control, 
power generation, and distribution, electronic products & telecommunications. 
Customized software has grown in importance as banks, government services, and 



management’s of large institutions have become increasingly dependent on computer 
based technologies for routing operations and management. Packaged software has 
become, the driving force behind the development of the personal computer sector 
and the principal source of its diversity,” (Cane, 1989). Many varieties of packaged 
software are used in such diverse areas as office automation, productivity tools, 
computer aided design, engineering, education, and manufacturing. It is what can be 
called an “overriding activity” that like mechanical engineering cuts across many 
different sectors in many ways, requiring a new range of skills and knowledge. 

Software is a booming sector and is growing faster than most other industries. The 
market for computer software and services is global, intensely competitive, fast 
changing and fast-growing. The global market, in 1 996, for software is estimated to be 
anywhere in between US$ 200 Billion to US$ 300 Billion. This industry has shown a 
growth rate of 20% and is estimated to continue at around 15%, globally (Schware, 
1992). 

Thus software export is being increasingly seen to hold promise for many third world 
countries in dire need of boosting exports (Schware, 1992 ). Also, there is potential for 
high value addition. India has been giving it lot of importance since 1989. 

1.2 The Indian Scenario 

1.2.1 Strengths 

Over the years, the Indian software industry has built an enviable global reputation for 
low costs and high quality. The spiraling revenues reflect this trend. Exports have 
grown from Rs. 50 Crores in 1985, Rs. 1,535 Crores in 1994-95, to Rs. 2,410 Crores 
in 1995-96. The Indian industry has grown at a rate that is double the world average. 



In 1994, the export’s growth rates were 52%. in 1995-96, exports grew by 57%. In 
dollar terms, these revenues are at a figure of $ 725 million. This far surpasses the 
World bank predictions, made in 1992, of $660 million for 1996. The industry is a net 
earner of foreign exchange. The earnings have risen to 45% of the total software 
exports. A total of more than 150 companies exported software worth Rs. 1 Crores 
each in 1996. There were only 10 companies in this category in 1990. In terms of 
markets, the USA accounted for more than 50 percent of the total exports. Exports to 
the Europe accounted for 22% (NASSCOM 1996 ). 

On the quality front, India has been exceptional. Forty-one companies have qualified 
for ISO 9000 certification and many others are in the process of doing so. The Indian 
software industry would have the largest number of ISO 9000 certified companies in 
any industry, anywhere in the world (BusinessWorld, 1995 ). 

So it is not surprising, that a recent World Bank survey of US companies rated India as 
the first preference for sourcing software and services. This, against seven competing 
countries — Israel, Ireland, Singapore, Philippines, China, Hungary and Mexico. Over 
104 out of the Fortune 500 companies’ outsource to Indian companies. With such an 
established reputation, the Indians are now looking towards new markets in EEC, 
Australia, South Africa, Japan & the Asia-Pacific regions. 

Considering such an encouraging performance, the Department of Electronics (DoE) 
has formed a committee to study the software industry and its export potential. This 
committee is part of DoE’ s 9'^ five-year plan (1997-2002). This committee intends to 
target Rs. 21,000 Crores by the year 2002. The chairperson of this committee said that 



a paradigm shift is needed to boost software exports to 10 times the present levels 
(Express Computer, 1996 ). 

1.2,2 Weaknesses 

What makes the paradigm shift necessary? The performance so far has been excellent. 
Yet all is not satisfactory for the future. 

The basic competitive advantages Indian companies have exploited have been its low 
cost, high quality English speaking technical labor. Software as it is built today, is still 
very much crafted. Use of software engineering tools is still not prevalent. 
Technologically, the prevalent use of such tools will change the way software is built, 
in a manner similar to the Industrial Revolution, where the craftsworker was replaced 
by mechanized tools. Under such a situation our labor advantages will simply vanish. 

In the trade magazines’ complaints & criticisms regarding our software industry 
abound. For example: minuscule global market share; strategically weak segments; low 
value addition, absence of innovative & quality product (or packaged software) 
companies like Borland, Netscape, Microsoft, etc. These complaints are valid. Most of 
our companies have had a short term focus on earning foreign exchange through low- 
cost strategies (Schware, 1992 ). Hamel & Prahlad (Hamel & Prahlad, 1989) explain 
the folly of sticking to low cost strategies. Regarding the Japanese industry’s rise in the 
world market, they say.' “They [the Japanese companies] moved from inexorably 
from less defensible advantages such as low wage costs to more defensible 
advantages like global brands.” “These cost-based advantages were vulnerable to 
changes in labor costs, process and product technology, exchange rates, and trade 
policy. ” Partly due to the strategies being followed, partly due to the changing world 



situation, technologies and markets, our current pre-eminence is threatened.. Reaching 
the DoE mentioned target is well nigh impossible using current strategies. 

The changes listed above by Prahlad & Hamel, have already taking effect, or are 
imminent. The intricacies of startups now have given way to other concerns. Rising 
salaries, infrastmcture problems at home, and the like squeeze the operating profits 
through rising costs.. As mentioned above, improved software engineering technology 
(CASE tools) will negate the current software development process. Growing 
competition from not only the World Bank mentioned countries, but also from Brazil, 
South Korea and Taiwan, looms large on the horizon. In this context of maintaining 
competitive advantages, the ISO certification is just the minimum step to keep ahead in 
the global market. As Prahlad & Hamel say, “... Western & Japanese alike are all 
converging on similar <& formidable standards for product cost and quality — 
minimum hurdles for continued competition, but less and less important as sources of 
differential advantage. In the long run, competitiveness derives from an ability to 
build, at lower cost and more speedily than competitors, the core competencies that 
spawn unanticipated products. ” 

Thus, the current concern in the industry and policy makers is how to take their 
businesses & Indian software into the next phase of growth in the global market. India 
and its companies have an established reputation now, a small but appreciable market 
presence. There is still a lot more to be desired. On the agenda is what to do next and 
how. DoE says that a paradigm shift is needed to reach 21,000 by 2002. Many an 
article says that we must start developing & marketing software products. But then 
how to go about it? When the competition is increasing, we need to manage our firms 



better. We do not have the reliable knowledge of how to manage software firms better. 
Are there some models that we can adopt for the improved management of an Indian 
software business? 

1.3 The Scope of The Thesis 

This thesis is an attempt to make a contribution in this direction. The focus of this 
thesis is exclusively on the software industry, and not on the associated, larger 
information technology (IT) industry. Its focus is on the companies that make software 
in India. The thesis differentiates the companies on the basis of their output: either 
service or product. It does not actually focus on the exports’ business or domestic 
markets. The thesis does not mention how to do product marketing etc. It does not 
delve into the software technology that must be used to develop products. It confines 
itself to the organizational matters of a software company. 

1.3.1 Overview 

This thesis subsumes that moving to product development is the paradigm shift 
required in the India software industry. It aims to find the means to achieve this shift at 
an individual company’s level that is what changes would have to be done to move into 
product development. So we search for and find, an evolutionary paradigm that lets 
us continue and improve our current business in the short term. It also sets us on the 
path leading towards product development for the long-term. 

Given that most Indian software companies are into providing ‘software services’, we 
hypothesized that the services management literature should help us achieve our short 
term interests: to continue to provide services. If the software service providers 
resemble service firnis than we can apply service management knowledge as a way to 



improve the business. Studying the product developing firms could enlighten us as to 
what they do differently. The features shown by the product companies are indicative 
of the changes or competencies that the service providers have to acquire to become 
product developers. The service literature suggests ways in which the service strategies 
may be used to evolve into software product developing firms. 

1.3.2 Objectives 

The research objectives of this work are 

1 . To verify if software service companies resemble a service organization. 

2. To observe how a software product firm differs from service firm. 

1.3.3 Relevance 

The software industry is too recent to have ready made business management models 
that could be taught and applied to improve the businesses. Applying the knowledge 
from the service literature gives us a tested and known way to improve our current 
services businesses. 

Successfully proving the applicability of a services viewpoint gives the manager a 
readily available, tested model that can give immense insight into how to better manage 
people, operations, business strategies and view markets. This should be of immediate 
value to the software managers in the service firms. 

Global trends indicate the growing market share of software products. Applying the 
service strategy of focusing on niche areas and vertical segments through continuos 
improvement and learning provides a smooth way- to transition into quality product 



developments in a few years. This can help in developing business strategies for the 
near future. The evolutionary nature lets the firm change without sacrificing current 
interests or radical departure from current strategies. 

The software literature has focused mostly on software engineering. Literature related 
to software management has confined itself mostly to individual projects and teams 
producing software, or to situations in the Data processing or Information services 
departments that develop software for the limited use within a larger user company. 
There has been very little work and that too very recently that deals with companies 
that develop software only for the market at large. This work is a small step towards 
filling this large void. 

1.3.4 Structure of the Thesis 

This chapter introduces the software industry and gives a brief overview of the thesis. 
The next chapter reviews the literature. The software industry is a very recent industry 
and has some peculiarities. The first 2 sections of the literature survey attempt to 
provide some insight into the industry and the peculiarities of software itself. Then 
some important sources are reviewed that explain the state of the Indian software 
industry and its salient features. These papers highlight the predominantly software 
service nature of the Indian industry. These thus suggest the possibility of using a 
service management based framework to understand the management of our software 
firms. 

The third chapter builds the research framework. The services literature is taken up 
based on the traits of the Indian software industry as suggested by the literature 
review. The fourth chapter explains the methodology. 



The next chapter onwards deals with the data and its analysis. The data collected is 
explained in 2 chapters, the fifth and the sixth. The fifth chapter introduces the 
organizations and details the organizational structure. The sixth chapter presents the 
remaining cross company data in view of the research framework. 

The seventh chapter summarizes and analyzes the data. The last chapter discusses the 
conclusions to be drawn, the learning’s from the work. This chapter also discusses the 
strengths and weaknesses of the present work and mentions some of the possible 
future work that can be done. 



Chapter Two 


2. The Literature Survey 

“Software production may be the first business activity of the 
Information Age. The factors driving profit, revenue, and costs are quite 
different from those of the Industrial Age. For example, the replication 
cost of word-processing software (copying and mailing a diskette and 
manual) is insignificant compared to the replication of a car in an 
assembly line” — Olsen (1994 ). 

2.1 Introduction 

Broadly, the problem is of strategic management and a search for management models 
for software. Thus the early literature scan was made with an intention to uncover 
material on managing software companies, managing software development, & anything 
on the Indian software industry. Some key papers on strategic management were also 
reviewed. This chapter develops a background for understanding the business of 
software and builds up to the research framework. First the strategic issues are 
explained, then the nature of the software delved into. These two sections are primarily 
to further understanding of peculiarities of software and some business issues 
surrounding it. After this background, the dynamics of the software industry are 
explored. The literature suggests that a service conceptualization of the software 
industry seems a promising avenue to understand the workings of the companies. This 
idea is arrived at in this chapter and the next chapter develops the framework based on 


this idea. 



There was found to be very little management literature specifically focused on the 
software industry. What is available is spread thinly across journals and the trade 
magazines. The literature search revealed three articles of significance. These specifically 
dealt with the Indian software industry. Yoffie (1994) is probably the only author that 
was found to deal explicitly with the strategic issues in IT. 

2.2 The Strategic Issues in Software 

Yoffie (1994) highlights some interesting traits that are common to the IT industry and 
cuts across all the subsets (see Appendix 1). The points to note are that 

1 . The industry is inherently global in scope. As mentioned in the introduction 
earlier, IT has become an infrastructure industry, the demands for which are 
the same world wide. This implies that companies must have an international 
mindset from the outset. 

2. Yoffie also notes that the managers in this industry have to be technically 
proficient to survive. The tremendous rate of change in the technology would 
necessitate technically competent managers. 

3. He remarks on the strategic advantages of being the first. This coupled with 
the rapid technology change demands that one bring out new products 
incorporating the new technology to replace the still successful product that 
incorporates the old technology. That is, the early bird gets the market. The 
effort to dislodge entrenched 1^ movers is possible by using the latest 
technology to make obsolete older technology based products. In other 
words, the one’s first to utilize or exploit the latest technology will reap 



tremendous benefits. Thus to prevent being shunted to the side, one has to 
continually invest in acquiring and incorporating new technology. 

4. Yoffie also clearly lays down the alliance-friendly nature of the industry. 
This goes hand in hand with the global scope. For example, Apple Inc., IBM 
& Motorola aligning together for the PowerPC combine, the ‘winter (MS- 
Windows & Intel) alliance, etc. Companies with different strengths band 
together to complement each other’s skills. 

5. He describes the blurring of the boundaries among industries and across 
segments. To illustrate the point, Microsoft is into computer games as well 
as into operating systems. The recent spate of mergers in the US shows the 
hereto channel providers like McCaw venturing to be content providers as 
well. On the other hand, a company like Netscape has turned into a phone 
company with the netphone technology in its software. This blurring of 
boundaries is accompanied by everyone developing capabilities in software. 

The significance of Yoffie’s descriptions is in l-irbf'hf'ig the strategic challenges that 
the management model must incorporate. As we move towards our objectives of 
searching for a suitable model, we shall depend on these traits mentioned above to guide 
our assessment for suitability. 

2.3 The Nature of Software 

This section attempts to highlight the nature of the software that makes it difficult to 
apply general management techniques (see Appendix 2). What is it about the technology 
that needs to be mastered? We will attempt to see what makes software different. This 
section is an attempt at gaining some insight as to what is software. 



There has been considerable dissatisfaction with the development & use of software. 
This has been often called by the term “Software Crisis” (Pressman, 1987 ). That it did 
not deliver the required results; failed at critical junctures; most common: simply took 
too long and costed much more than the budget, (these complaints can be found 
reiterated in the introductory chapters in almost any text on software engineering or 
articles in early issues of IEEE Software, Software Practice & Experience, etc.). 
Comparisons have been made with other engineering disciplines and many conclusions 
drawn as to its inherently different nature as the source of management problems (for 
example see the USENET discussion in Appendix 2). 

Easily among the most celebrated books in the software arena is the classic by Brooks 
(1975 ). The book’s 25‘*' year since first publication was celebrated with a special edition 
and considerable coverage in the professional journals. His opening sentences seem to 
prove Yoffie’s comments on mastering technology. “In many ways, managing a large 
computer programming project is like managing any other large undertaking — in more 
ways than most programmers believe. But in many other ways, it is different — in more 
ways than most professional managers expect.” Further on, he states “This book is a 
belated answer to Tom Watson’s probing questions as to why programming is hard to 
manage.” Brooks answers the questions in the first chapter (See Appendix 2). Among 
other points that characterize software programming, he lists the medium’s tractability, a 
nonrepeating nature of job, the lack of control over the goal of work, or its 
circumstances and lastly, the rate of obsolescence. He regards the systems product as 
the ultimate goal of every programming effort. The key feature of this is its 

ft 

generalization. Not only in terms of inputs or algorithms but also in terms of its 
availability & applicability over various systems, and also in its usage with other 



programs/products. Brooks also emphasizes the testing and documentation as part & 
parcel of the product. 

Yoffie & Brooks are of one view regarding the rate of obsolescence. An important 
feature that is brought out by the USENET discussion in Appendix 2 and highlighted by 
Brooks, is the power & effect that other people have over the programmer of the 
product. The software is made to fulfill some objectives. The software engineer codes 
the software, but he is not the one whose objectives the software is to fulfill. This person 
whose objectives are to be fulfilled is the person who affects what work the software 
engineer does. Often this is the management. Or as the USENET discussion mentions, a 
key customer. The discussion also highlights the tractability of software, as does 
Brooks. The customer/management understands the tractability of software, but not the 
difficulty in making changes correctly. Thus they may change what they want, and force 
the software engineer to implement those changes, without giving sufficient resources to 
implement the changes correctly. Deadlines are not met or the software is faulty and the 
customer is dissatisfied resulting in penalties to the software engineer. 

Most of the problems mentioned regarding the development of software are addressed 
by the field called software engineering. And there has been an explosion in this field as 
it has matured since ‘The mythical Man-Month”. The field does not deal with the 
business management aspects of software. A lot of software development activity has 
traditionally taken place within larger organizations and the literature seems to reflect 
that focus. Yoffie (Yoffie, 1994 ) has written some cases with regard to one or two 
software companies. There seems to be a vacuum in the literature regarding the 



organizational structures in software companies, as opposed to the MIS or EDP 
structures in a company. 

So far, we have seen the characteristics of the IT industry and then we have understood 
independently, the characteristics of software. We now see what the literature says 
about software industry and in particular the Indian industry. 

2.4 The Nature of the Software Industry 

Jain & Bhatnagar (1991), Korwar (1991) and Schware (Schware, 1992) describe the 
software industry and concerned themselves with the Indian software scenario. 
NASSCOM’s periodic reports provide one with information on the current status of the 
industry. 

Schware (1992) was helpful in gaining an idea regarding the world Software sector: 

1. There are two key market segments — Software packages and system 
integration services. System integration’s includes project management, 
requirements’ analysis & design, contract programming, subsystem 
integration, education and training and ongoing support and maintenance. 
The software packages or products, are like OS packages, DBMS packages, 
generic and vertical application packages. For example MS Word, Matlab 
that are generic; vertical application packages are like EX, Tally, 
Microbanker which target a specific area like accounts or a specific industry 
like banking. 

2. Sector Dynamics: There is a trend towards the production of packaged, 
‘shrink wrapped’ software away from customized programming services. 



Another trend is the verticaJization of the market. The software market has 
become ever more specialized by end-user segments (italics ours). This is 
because each sector has its own characteristics in terms of data processing 
expenditures, environment, level of information intensity, and importance of 
vertical applications. Traditionally, end-user sectors have been segmented as 
financial service, manufacturing services, and government & defense. But 
this segmentation is also changing, as other subsectors become attracted to 
developing software. There is increased evidence of former users of IT 
coming up with their own products in their sectors to make profits of their 
investments made for their internal use. 

Changing Skill requirements; “Software development is not an easy task 
since there is no simple set of rules or methods that work under all 
circumstances”. There is considerable agreement in the software industry that 
experience plays a very large role in the development of a good software 
engineer. “Software is still a craft sector, which depends on talented 
people — perhaps the most important element in any software organization”. 
A lot depends on the software organization’s approach and management of 
the entire software process. There is going to be a long-term decline of 
routine or low-level programmers, and an “increase in demand for higher 
level computer, software, & communications expertise, with business 
knowledge.” There will be an increase of the growth in the end-user 


computing. 



After explaining the world scenario, he goes on with 2 case studies of India and 
Brazil. These third world countries have diametrically opposite approaches to 
develop their software industries: India through software exports, Brazil through 
encouraging a vigorous domestic market. The main thrust of this paper is that for 
sustained world standard’s performance, both the approaches are needed eventually; 
neither alone is successful. He advocates a ‘moving from domestic to exports' 
strategy involving products. The domestic market he says helps to develop 
capabilities in the market niche, to form skills and diffuse knowledge within the 
company. He supports his idea with an example of Kale Consultants in India. 

Regarding India’s case he has the following points to make: 

1. Emphasis on low-level programming overseas: India’s software sector as 
focused on onsite services abroad, known as ‘body shopping’ or ‘manpower 
contracts’ in which Indian firms undertake mostly the routine task of coding 
and debugging rather than design, analysis or project management. 

2. Plans Vs. Performances: The government makes over optimistic plans based 
on alluring data available on the ‘world’ software market. But piecemeal 
policies make these plans far-fetched. “The right policies in this sector should 
lead to building higher level skills in software engineering, improving 
communication infrastructure for tie-ups with foreign software firms, and 
making available the latest software and development tools for producers. As 
a result of not having these policies in place, the software companies and 
government have generally supported an export, labor-intensive approach”. 



3. Labor demand and supply imbalance — the low-skill trap: “It should be noted 
that at this time there is no formal or informal training program for software 
engineers in India, and no training covers project management.” There is a 
low supply of software engineers and that the supply of system analysts is 
restricted to the in-house training done mostly by firms. “In sum, government 
initiatives and private sector training organizations have mainly produced 
trainable labor with an aptitude for data entry and coding while the industry 
increasingly needs trained labor for analysis and management.” The focus on 
onsite-programming service in export work has for India resulted in a 
tendency to be self reinforcing, with analysts lost to foreign companies or 
never developed. 

Overall Schware paints a gloomy Indian picture. The points to note are the movement 
globally towards products and verticalization of markets according to end-user 
segments, the Indian focus on low-level coding services, and the improper labor 
situation existing in India. Today, we are in 1996, and the situation has changed for the 
better, since his paper. Offshore projects have begun to bring in bigger chunks of 
revenue compared to onsite services, but still the onsite business is markedly high. This 
situation implies that India has acquired some project management skills, the lack of 
which, Schware bemoans. Though we now do more offshore projects, most of these 
projects are still the coding ones. 

Bhatnagar & Jain (Bhatnagar & Jain, 1991) analyze the Indian industry in great detail. 
They first state the traditional market segmentation of the software market. They are: 
Packaged software. Customized application software. System Integration, and 
Processing Services. Each of which can be further subdivided on the basis of hardware. 



software platform on which the package/application is implemented. Then they analyze 
the global trends, stating similar trends as Schware. They state the sectors that India has 
exploited in the past. India has largely exported software in the customized applications 
software segment & in development and coding projects of system integration. Of the 
customized development market segment, they identify some sub-segments — ^projects 
involving the fuU software development cycle (specification, design, coding etc.); 
projects involving coding only; and projects involving maintenance of software*. 
Traditionally India has tapped the market for coding, which is low risk, low value- 
added. The primary advantages were the plentiful availability of low salaried 
programmers here, and their English speaking nature (English speaking markets were 
62% of the world market (Schware, 1989) ). They state that this segment is only 1.7% 
of the world software market. Of this segment, India had about 4.3 % share in this 
market. 

They then analyze the international competition for exports and the Indian software 
industry’s growth. And propose some suggestions. They find the current segment to be 
under threat of advancing software technology like CASE tools that does away with low 
level programming. Also they state increased competition from not only other third 
world countries having cheap labor but also from the exports of developed countries. 

They advocate a multipronged strategy that calls for entering other segments of markets 
existing in the world. For the turn-key segment, they advocate developing market niches 
by specializing in selected applications/industries. In the turnkey projects’ segments. 


‘ These are now called re-engineering projects that involve transforming the functionality of the old system on to 
newer hardware and software platforms. This may even be conversion of the old system from it old language 
COBOL to using the more recent C-t-+ , etc. 



competitive advantage is derived from prior knowledge of a sector and a demonstrated 
ability to design and deliver the software. They also recommend going into the products 
segments, by utilizing our traditional strengths of education, rural development. They 
advocate going in for such specialized markets, which would be small, attract lower 
competition. 

The main thrust of this paper is to enter vertical markets and in time, bring out products. 
They highlight the vulnerability of the current focus of the Indian software industry. 
Since the time of the paper, things have improved. The communication links that they 
advocate are now in place. The lack of suitable training facilities they mention is not so 
critical, though it still exists. Both, Schware above and this paper mentioned the lack of 
availability to hardware. Today, this problem is not critical anymore. Yet even today, 
most of the smaller companies do depend on the onsite services. And even the more 
established players earn a huge chunk through onsite services. 

Korwar (Korwar, 1991) analyzes the structure of the industry using Porter’s framework. 
His market segmentation differs from Bhatnagar & Jain. Korwar identifies a ‘Systems 
management’ segment besides the customized software segment. He notes that the 
most important success factor here is “the deep, ongoing knowledge of the customer’s 
business.” To gain this, he advocates going in for strategic alliances with suitable firms 
abroad, so that the Indian employees get access to world-class business practices. He 
notes that India’s competitive advantage lies not in price but availability of people. 

All the three papers reviewed above note that most of the companies in India are into 
the software exports business with a short term vision limited to making foreign 
exchange. All agree that relying on the current business strategies are not viable in long 



term. They all bemoan the dependence on the coding segments of the market & note its 
vulnerability. They aU, in different ways suggest rising along the business processes & 
value chains of the customers. 

The Indian authors suggestions seem to be based on an analysis of the markets and other 
secondary information. There was no literature available that mentioned the internal 
operations of the software companies. 

The papers mentioned above are of the early ‘90s’. Now we move onto the data 
available today describing the current state of the industiy. NASSCOM (NASSCOM, 
1995) states that the bulk of the Indian software activity has been in the ‘professional 
consultancy’, ‘customized ‘ or ‘turnkey ‘ project development. That is the projects 
involve developing software according to the specific requirements of each client. Just 
above 60% of the work is being done “onsite” (i.e. developer is at the client’s 
workplaces). The “offshore” (i.e. the developer is not at the client’s site) development 
was 38% of the total exports and is expected to rise further. There are said to be more 
firms in India who provide such software services. 

“Products & Packages “ are around 38% in the domestic market; 10% in the export 
market. These products are standardized software that are built from generic 
requirements i.e. not built with a specific client in mind. e.g. DBMS, word processors, 
etc. These figures include products made elsewhere (not in India) and then sold from 
here. 

The 1996 report released in June 1996, (Express Computer, 1996) mentions that 1995- 
96 saw an unprecedented global outsourcing shift towards India. Out of the Fortune 500 
companies, 104 outsourced their software requirements from India. The onsite services 



contributed to 60% of the export revenues, with offshore 40%. Given the tremendous 
amounts of growth rates, and the supporting market trend, it appears that India has an 
established brand identity in the program outsourcing market. Our quality track records 
and the an established image among the clients give us Yoffie’s ‘first-mover’ 
advantages. In the sense that compared to the other developing countries vying to 
exploit the huge software market, we have established a reputation before the others. 

2.5 Identifying the Framework 

Reviewing the information above, clearly the world market is growing. In such 
conditions, any and all companies can make earnings. A serious incongruity strikes that 
though the world wide trend is towards packaged software, the Indian industry is 
making hay in a vulnerable niche. In the domestic markets, India has not many products 
and those that are, have not had the impact that packages as Lotus- 123 had in the US. 
Why is product development lagging in India, especially in the exports segment? 

The papers above suggest moving into associated areas. But there is no mention of how 
and what changes the organizations must undertake to be able to do so. There is no 
mention of how to manage this change. There are some other papers, but none mentions 
solutions on an organizational level. In our search for information on the management of 
software businesses, we found only industry wide suggestions. There is a need for 
understanding how Indian software companies function. 

Brooks, Schware and a host of others note that managing software is different. The 
software industry itself is recent enough not to have developed sufficient knowledge 
about its own management. Then which among the streams of business literature can we 



turn to, to understand the workings of our software organizations? How do we classify 
the organizations so that we can begin to understand its workings? 

All along in the literature is the mention of software services and software products. Yet 
there is no paper anywhere that explains the differences in providing these. So suppose 
we were to stop thinking of our software companies as software organizations. Instead 
what if we start thinking of them as organizations providing just services and products? 
Ignore that they are in the software market. We find that a whole new approach seems 
to open up. If we ask the fundamental question “what business are we in?”, we must be 
wary of an answer of “in the software business”. From what the papers suggest, it would 
be better if we described it as “in the business of supplying manpower, more particularly 
programmers”. Even today, with increasing off shore work being done, essentially we 
are supplying programmer services, not software services. Which is what Korwar 
explicitly points out (see above). This is an unmistakably service operation, albeit hi-tech 
manpower service. One may say that it is too much of a simplification. The point is not 
of oversimplification. The point is utility. Given the software industry’s greenness and 
it’s acknowledged management difficulty, how much insight and guidance can we draw 
from being “in the software business”? It seems better if we redefine our current state as 
being “in the service business” or if more precision is required, “in the personnel services 
business”. This is more useful to us, given the state of knowledge in the services domain. 

One finds that there has been a sufficient amount of research in the services sector of the 
economy and the results are now out of the research journals and into the popular 
domain. And services too have been established to be very different from traditional 
manufacturing and other industries. The insistence of the software experts (as typified by 



the discussion in Appendix 2) that software activity is different from traditional 
manufacturing can be seen as an implication that software activities could be similar to 
service activities. 

Riddle (in Bowen et al., 1990) mentions that services must view itself as operating in an 
international environment with regard to multi-cultural customer groups and potential 
foreign competitors, though they be targeting domestic customers. This implies that 
services too are inherently global in nature. This matches with Yoffie’s comment on the 
IT industry. As Brooks notes, that other people control the actions and goals of 
software programming. This is akin to the services problem where one is dependent on 
the customer, controlling the service provider’s actions. Heskett (in Bowen et all, 1990) 
notes developing customer switching costs as a service strategy. This resembles the 
lock-in phenomenon Yoffie observes. He goes on to remark that services suffer of an 
ease of duplication of a service and that nothing remains proprietary for long. This 
would suggest a situation similar to the IT’s needs to cannibalize present successes. 
Riddle further emphasizes creating strategies that prevent easy duplication of services to 
maintain competitive advantage. This compares with trying to lockout competitors in IT 
industry. This is a trend seen among the IT industries. E.g. Apple first incorporated the 
GUI (Graphical User Interface), soon Microsoft duplicated it and now a GUI is a de 
riguer in the software domain, irrespective of the platform. 

Given the above comparisons, the services model seems very suitable means of viewing 
the software companies. This has the advantage of being an established body of work. 
This kind of view seems more appropriate given NASSCOM’s figures of “professional 



services” dominating the Indian exports. It will help us to understand software 
management, if indeed the software services can be managed like any other services. 

This chapter created the background for understanding the software industry. It 
described the progression of the literature survey that leads to the services framework of 
the thesis. It shows the rationale for adopting this body of literature to view the software 
companies. The next chapter explains the utilization of this body of literature to 
formulate the research objectives and establish the research hypothesis framework for 
the study. 



Chapter Three 


3. The Research Objectives and Framework 

3. 1 The Research Objectives 

In the first chapter, we began our search for management models to conceptualize the 
software industry. In the previous chapter on the literature survey, we arrived at 
selecting the services paradigm as a promising way to understand our software 
industry. We mention the literature on the software industry. Though the literature 
does not mention any management model, the terminology expressed, directs us to 
one. The emphasis that Indian companies are only into the software services; 
NASSCOM’s report that the bulk of the income comes from ‘professional services’ 
‘consultancy’, etc. suggests that we could conceptualize the companies as being 
service providers and ignore that they are in the software business. This chapter builds 
on that idea to arrive at the research objectives. 

We proposed that the services framework appears a favorable conceptualization to 
examine this industry. Now how to test if the framework is applicable? To do this, we 
have to find if the software firms resemble or display characteristics typical of service 
organizations. We have to find if those companies that produce software products 
display different characteristics from the service organizations. And what are the 
different characteristics? 

What is the use of such a framework? If the two are indeed different, we would have 
gained some foothold in developing appropriate management models for this industry. 
By drawing upon the services literature and experiences, we can make definite and 



tested suggestions for better managing the firms. The least one can be sure of is that 
there is a body of knowledge to draw similarities and adapt for the current situation. In 
the process we would have gained some idea on the operations of software businesses. 
The service companies could prefer to stay in the service segments. Then by adapting 
the service literature for their purpose, they learn to manage as a service firm, improve 
their organization & operations to stay ahead of the competition. By comparing their 
differences with the product companies, suggestion for an evolutionary path can be 
found. Given the strident need to develop products, this would be very useful for the 
predominantly ‘software services’ oriented Indian companies. 

More clearly stating, our objectives are to find: 

1 . Do the Indian software service companies resemble typical service 
organizations. 

2. How do Indian software service companies differ from their product 
developing counterparts. 

The focus in this study is on those firms who develop software within India. The 
objective stated above does not exclude companies with non-Indian ownership. It 
encompasses all those that operate from India, that are based in India, who do 
development work in India. It excludes companies who develop outside India but have 
a presence in India. For example the distribution of imported products lies beyond the 
scope of the study, and the focus will be on that sub-unit of the organization that is 
doing developmental work here . The distribution of imported products, does not 
impact on achiveing the DoE set targets. Developing from India and then selling it 
leads to the increase of the industry’s revenues, which is what we are attempting to 



aid. We assume that product development is the paradigm shift required to achieve the 
DoE set targets for 2002. With this assumption, we study the differences between 
product and service software companies in an attempt to find what is needed to change 
a company from a service oriented strategy to a product based one. We thus develop a 
framework that seems to explain the workings of a software service company. We wOl 
observe how a product firm differs from this framework. 

We now have to identify the service characteristics that ought to be displayed by the 
software service organizations. Before that we will have to define the terms service & 
products. 

3.2 Building the Framework 

So far we have discussed service and product. We now explain these terms in the 
context of software. 

3.2.1 Definition of service & product as used in the study 

Gunther (Gunther, 1978 ) states the assumptions that differentiate software products 
(Ref. Appendix 3). Considering his assumptions, and the definitions given by Bowen 
(Bowen et al, 1990) (refer Appendix 3). This study uses the criteria given below to 
distinguish between the software service and software product. 

1 . The source or acquisition of the specifications (requirements) for the output. 

2. The customer’s involvement in the transformation of the specifications. 


3. The intended end user(s) of the output. 



From the above, Service is defined to be the outputs that are produced for use by a 
specific customer, on the specific request of that customer, who remains aware and/or 
involved in the transformation of the requirements that have been arrived at by 
common agreement by the provider and the customer. 

A Product is defined to be the outputs that are produced for use by a non-specific 
customer, who is unconcerned with the transformation of the requirements, that have 
been arrived at by the provider in an independent fashion. 

That is products are standardized software that are built from generic requirements i.e. 
not built with a specific client in mind. This is the same as Brooks (Brooks, 1975) 
requirements for a programming systems product. The above definition also implies 
that the customized software developed is used only by the customer (see Marx’s 
comments. Appendix 3). 

Thus Service firms are defined as those firms whose 60% or greater revenue comes 
from the delivery of software service packages for the clients. Product firms are 
defined to be firms whose 60% or greater revenue comes from the delivery of 
software product packages. 

Please note, that there are rarely pure service companies and rarely pure product 
companies. There are degrees of their mix (Kotler, 1994). For the purposes of the 
study, we take them to be pure. Including the in-between types will complicate the 
study. It will divert us into the intricacies of the definition of product and services i.e. 
when does a company begin to be called a service company and till when is it a product 
company? Here, all we need is a gross identification of service-like or product-like 



3.2.2 Distinguishing Features 

The services literature (Bowen et al, 1992) espouses the thought that if the 
prototypical service differs from a prototypical good then the systems by which goods 
and services are produced may also differ. Above we have defined the services to be 
different from product. Therefore one would expect the organization that produces 
these to be different from each other. Appendix 3 excerpts issues arising in services 
organizations. Considering these issues, we develop the points for observation that 
would indicate a service orientation or not. The focus is on finding organizational 
characteristics that would facilitate in distinguishing. 

Firstly, we would expect the role of the customer to be different in the two cases. The 
services production would not start till the customer proposes the requirements. Also, 
we would expect the customer to involve in the development process. Not so in the 
product company. There the product develops without a customer’s prodding. Hence 
the first point of observation is the origin of the requirements and the customer’s 
involvement in the developmental process. 

The marketing function should be the next point of difference. According to services 
management (Bowen et al, 1990), The marketing of the service is not easily decoupled 
from its operations. Besides marketing skills, the technical competency of the service 
provider is important (refer Appendix 3, the customer — service-provider — technology 
interactions). Hence the fellow who does the marketing job or who contacts the 
customers should come across as knowledgeable and competent. So he should have 
had development experience. The marketer would be one who has been through the 
development operations. The true power to retain the customer lies with the service 



provider, t±ie developer in this case. Therefore the developer must also display 
marketing skills. The marketing role of a personin service would be more of a liaison 
than true marketing. The product firm instead can isolate its development task and thus 
it should be having a need for specialist personnel for the marketing task. In selling a 
product, it would be more important to be able to convince the customer how the 
product is useful to the customer. Technical competency on part of the seller will not 
be seen as an implication of the technical perfection of the product. There is no 
requirement that the marketer have been part of the development team. 

Now a third feature that should distinguish between the two has similar origins as the 
above. This is the specialization of activities of the software lifecyle. If it is not easy to 
isolate the development from the marketing, and there is little control over supply and 
demand, than for efficient functioning, the services firms should show multiskilling. 
There is another thing involved. If the technical relationship between the customer and 
the service provider has to be intimate to foster free flow of information, then changing 
the service providers midway through the project may not be permitted easily by the 
customer. If the personnel are specialized, they would emerge as bottle necks, by 
getting blocked with a lesser numbers of customers. This might not prove to be 
efficient utilization, specially given the current market situation. Thus it would be 
another disincentive to have specialized developers for each portion of the life cycle 
(See Appendix 2). For example, James Sims^(1995) mentions, in his company, the 
same people go through the entire project from first concept to the application roll-out. 


^ James Sims is the CEO of Cambridge Technology Partners. An interview with Sims was found in IEEE 
software. The business profile seemed to match well with what most Indian companies are said to be doing. 
The interview mentions a lot about how this company goes about its business. The descriptions matched very 
well with what the service management suggest. We took these as a prototypical software services company. 



The product company would have no such customer problems. They are in a position 
to isolate the developmental function, so they should show specialization of the tasks 
of the software lifecycle. 

Another point that should help us characterize and distinguish service company is the 
training & Human Resource Management. This is because the quality of the selection 
and training of the services personnel spills over to affect the customer’s perceptions of 
the quality of the service they receive. Since customer interaction is a necessary' feature 
of the service business, the personnel must have ‘people’ or behavioral skills. Sims 
mentions that the most difficult part of their hiring process is to find people with both, 
technological and behavioral skills. Thus the training aspect in service firms should be 
showing a prominence of interpersonal skills training for everybody. The product 
company should have no such need to train everybody in interpersonal skills. Nor 
would it play an important role in the hiring of the development personnel. 

In what kind of organization do the service companies work? Given that the service 
providers need more autonomy in carrying out their work, decentralization is required. 
Yet one needs standardization to achieve uniform quality in the service and cost 
effectiveness for the business to run. Also, the service providers must be highly skilled 
and trained. Under these conditions, Mintzberg’s definition of a ‘professional 
bureaucracy’ (Mintzberg, 1979) (also see Appendix 3) suits the organizational 
framework for service organization. For the product organization the ‘machine 
bureaucracy’ configuration should suit. This would seem right because of the 
differentiation between the marketing and development teams that we expect That is a 
functional grouping of people would occur in the product companies resulting in a 



machine bureaucracy kind of organization. A need for efficiency would prod a machine 
bureaucratic organization in product companies. 

3.3 The Frame work 

We can summarize the above discussion in the following points of the framework: 

I. Origin of requirements: What is the source of the requirements that drive the 
development process? What is the extent of the customer involvement in the 
development process? 

In service companies, the customer initiates the development work and is 
involved in the development process till the end. 

The product companies develop the requirements internally & independently of 
customers. And once generated, the development team has full control over the 
development work till the product is ready for testing. In this process, the 
customer is unaware and uninvolved. All that a customer can contribute 
towards the development work is feedback through suggestions. 

An effort is to be made as to broadly trace the process of the development 
work in both the cases. In particular how do the product firms get to the idea 
of their product. 

II. Integration of the Marketing task with the development task. To what extent is 
the developer involved in the Marketing? 



Service companies should have lesser forces devoted specifically to marketing. 
Those that are, have been technically trained in the development work as well 
or have been/are developers. They could be on a rotational basis. 

Product companies will have elaborate marketing arrangements. The personnel 
here will not be expected to have had development experience or technical 
backgrounds. 


III. Specialization of the development tasks. To what extent is the software 
lifecycle^ task specialized? 

Service companies will depict lesser specialization between the functions. 
Product companies will depict specialization in the tasks. 

IV. Training & Human Resource Management: What kind of training is given and 
what kinds of people are recruited and promoted? 

Service companies will emphasize interpersonal skills while recruiting, 
promoting and in training programs. All the persons who involve in marketing 
or development have technical training. There could be customer involvement 
in these aspects. 


Product companies will recruit depending on the expected placement, i.e. 
people expected to carry out development functions will be required to have 
technical qualifications. Those in the marketing aspects need not have technical 


^ The software engineering, life cycle (see Pressman, 1987). Functions start from the requirements generation, 
specification, highlevel design, low level design, coding, testing, installation, training, maintenance. Often 
included after testing is the documentation, generally it is expected to be an continuos parallel activity at all 
stages. Some texts do not include user training as an software engineering activity. Nevertheless, it is part of 
the cycle of software development and usage. 



qualifications. The promotions are based totally on the companies internal 
evaluation systems. The customer has no role at all in any of these functions. 

V. Organizational configuration. Into what departments is the company organized 
into? Are the companies organized functionally, or market wise, what are the 
numeric strengths of the departments?, etc. 

Service companies will not have elaborate departmentalization. There is no 
formal attachment to particular division. The persons will be allotted a group 
according to the ‘job’ on hand and demand across the company. The operating 
core would be dominated by developers. The middle managers or the senior 
managers would be the real arbitrators of business directions. The quality 
function is the technostructure but not so well established due to the 
customer’s being the final authority on quality. 

Product companies will show well formed and stable departments. People will 
be placed within the respective departments and expected to stay there and 
perform only that department’s job for all the time that they stay there. Formal 
transfers are the means of movement across departments and not easily done. 
In the operating core the developers numbers will not dominate the operating 
core as marketing too is equally important. The Strategic Apex here does have 
power and sets the business directions. The developer has lesser autonomy. 
The technostmcture is the quality function and should play a major role. 

In the next chapter, we will outline the execution of the research to explore the points 


above. 



Chapter Four 


4. The Research Methodology 

This chapter the explains the research methodology. The approach to the study, the 
decisions involved, the execution of the study and some of the experiences of the 
study are outlined. 

4.1 Methodology 

The case study method was deemed suitable as the means of conducting this study. As 
per Yin (Yin, 1984), the following indications suggest a case method. 

• The study is primarily of the ‘how’ type. We attempt to demonstrate if and how 
most Indian software companies resemble service organizations. We have to 
show that the product companies differ from their service oriented counterparts 
and how they differ. 

• The investigation concerns the companies as they are today, in their real life 
context. We have no control over the phenomenon. 

• The study has a slight exploratory nature. There is insufficient knowledge 
available apriori. To better understand the events we need to observe the 
context as well. We need some flexibility available if the reality data differs very 
much from our prepositions. 

The organization is the unit of analysis. A primary reason is the indication of the 
services theory of the inability of service firms to differentiate their operations from 
marketing and other aspects of the organization. Thus we would have to view the 



company in a holistic manner due to the expected tight linkages. The tasks of the 
marketing, development and their organization as well as the training aspects are 
primary concerns. Information on the other tasks like Human Resource Management, 
Finance etc. is needed to comment on the organizational typology. 

4.2 Identification of the Firms 

We need to look at firms that are stabilized, that are beyond the struggles of 
entrepreneurial stages. This condition implies that the firm has been successful and 
doing well. It would be in these kind of firms that the work processes and methods 
would have had time to stabilize. 

Also for our purposes firms purely into either service or products would be the best. 
The study intends to confirm if the service-product framework is applicable. For this 
we need companies that purport to be in the service business, firms that purport to be 
in the product business. 

We selected the companies from the publicly available “Top 20” or “key companies”, 
etc. annual lists. These lists specify the businesses the company is dealing in. For 
example, “Computers Today” in its “101 Key companies” lists the activities as 
‘software & consultancy’, ‘packaged software’, ‘Training’, etc. “Computers Today” 
also publishes an annual “Best selling Indian software” list that mentions the best of the 
Indian-made software. The “DQ Top 20” special edition of “Dataquest” has small 
write-ups on the companies that make it to their lists. There they mention the details of 
the companies, its market offerings, etc. 



Thus we identified thirty such companies that qualified for our purposes. They all were 
successful with revenues of greater than 10 Crores, had been in the market for at least 
2 years. 

4.3 The Data Collection Process 

We wrote introductory letters to the CEO’s of all the 30 companies. We mentioned the 
purpose of the study, who is conducting, and requested their cooperation for the study. 
We indicated the academic nature of the study and assured them of confidentiality. We 
had initial responses from 10 companies. The final study was conducted on 7 of the 
respondents. It was observed that the firms with Indian ownership’s were very open 
and enthusiastic in their wording. 

The study has been a confidential one and thus the names of the companies have been 
changed and not all the information that was made available is mentioned here. As far 
as possible, all attempt has been made to disguise the true identity of the company. 

The service companies will be indicated by the letter ‘S’, suffixed by a number to 
differentiate from the other service companies. The product companies will be 
indicated by ‘P’, with a following number to differentiate between other product 
companies. The company involved in both is indicated by ‘PS 1 ’. 

Of these 7 sites, 3 were purely service providers, 2 were pure product developers. One 
company was committed to products and had major revenues from product exports, 
but also had some customized software business. It has been included as a product 
company as its service operations were not looked into. One company had decided to 



focus on products and had begun its transition from service. This company provided 
services and also did product business. 

The following name convention is followed ; 

• The service companies visited are : S 1, S2 and S3 

• The product companies visited are : PI, P2, P3 

• The company involved in both is : PS 1 

After the initial responses were received, we collected secondary data on these 
companies. The sources were the trade journals like “Dataquest”, “Computers Today”, 
“Express Computer”, “PCQuest”, etc. 

After the travel plan was fixed, the visits were made in one trip covering all the 
companies. The time given to each company varied from a week to ten days depending 
on the availability of the interviewees. The person with whom we had corresponded 
with, was contacted. This person then suggested the persons to meet, after ascertaining 
who was available, and who could be the right person. Then a plan of appointments 
was made. The interviewees were informed and their confirmations were awaited. 

On an average it took at least 2 days before the interviewees responded and the 
interviews could begin could actually start. Meanwhile efforts were made to get 
documents on the company, like their marketing brochures, annual reports, etc. It was 
attempted to get the quality manuals of the organization before the interviews started. 
These manuals document all the processes of the company, personnel’s responsibilities 
at each level, the organizational structure, personnel policies, etc. It enables one to 



grasp as much of the company as possible and saves a lot of time and effort during the 
interviews. These documents are classified information and not easily allowed to be 
viewed unless the CEO or head of quality permitted it. These documents sometimes 
were made accessible towards the end of the stay at the company. Then they were 
useful in filling some gaps or clarifying some issues. 

The interviews took at least 20-30 minutes. Many were longer if the interviewee could 
manage it. Sometimes there were repeat interviews to clarify some details or 
interlinkages. These interviews were shorter, sometimes over the phone. Extensive 
notes were made during the interviews. The interviews were semi-stmctured. There 
was a small set of standard questions asked of every interviewee every place. There 
were other questions that would occur there to comprehend what the interviewee 
explained. The interviews began with introductions on both sides. The questions first 
focused on the interviewee: the person’s background, experience, period in the present 
company, etc. Later questions pertained to the work of the person, the group and the 
interactions of the person with superiors, and subordinates. 

The interviewees typically were the middle managers, heads of departments, or heads 
of groups or projects. There were interviews with some of the fresh developers but 
these were not often. There were also some interviews with the CEO. This was not 
always possible. 

There were no interactions with the people from finance. The interactions were limited 
to the people involved in marketing, development and HR. 



4.3.1 Presentation of the Data 

The data was sorted out as per the points of the research framework. They were then 
analyzed with a view to detect & explain similarities with the service literature. The 
data is presented beginning with the observations seen in the service operations, and 
later, the corresponding product operations. 

The data has been split into two parts. The first part besides presenting the 
organization of the companies, also serves to intoduce the company. The introductory 
details include information on the business of the company, its strategy, markets, some 
general or misceallanous information not included in the framework but observed and 
impressions. The basic purpose of the introduction is to get accross a greater feel of 
the company as a whole. This is then followed by the details of the organization of the 
company 

The second part deals with the rest of the points. That is the source of requirements, 
integration of the marketing with the development function, the specialization and the 
training and human resource management issues 



Chapter Five 


5. Data - 1 : The Organization 

This chapter and the next, present the data collected. This chapter serves to introduce 
the companies studied. The details of their organization are also included here. The 
next chapter discusses the rest of the points. 

5 . 1 The Service Companies 

5.1.1 The Company SI 

5.1.1. 1 Introduction 

S 1 is the software service division of the information technology subsidiary of a large 
diversified corporation. This corporation has interests in financial services, computer 
systems, software, lighting, edible fats, soaps, etc. The corporation is one of the top 
100 publicly held companies in India. SI was formed with the objective of providing 
software solutions to the world market. Initially it focused on products, and had a few 
successful products, some of which survive to date. After it’s first 5 years it had a 
strategic reorientation and went in for customized software development. This led to 
rapid growth and today it is one of the largest software services provider from India. 
Revenues as of 1995-96 are above Rs. 150 Crores. 

5. 1.1. 2 Strategy 

As of today, this division is committed to software services. Quoting its marketing 
brochure “S 1 offers a range of software services, with strengths in maintenance and 
enhancement, re-engineering, conversion, testing, porting, system study, and system 
development”. Some of the managers expected another shift in strategy back to 
products in the coming years. The firm goes in for long term development of 



relationships with some major clients. These often are developed by the first few 
people assigned to the client. They are supposed to find out how best to grow the 
business with that client. For other projects, the SBU (Strategic Business Unit) chiefs 
and the CEO do the planning. 

5. 1.1. 3 Market 

Among Si’s “clients”, it lists some fortune 100 companies, some of them being among 
the biggest telcom companies of the world, among others worldwide. SI believes in 
building its relationships with clients into long term partnerships. Its major focus areas 
are the United States of America, Europe and its large account clients. 

5. 1.1.4 Impressions 

At the city of its inception and its headquarters, the offices were spatially dispersed at 3 
places. SI has another development center in another metropolitan city. The study 
focused only on the development center in the home city. The President of SI, and the 
offices of the HR group are in one building. Most of the other departmental heads are 
■located in another building nearby which also serves as the primary development 
center. The development offices of the large account clients are physically separate 
from the offices of the rest of the projects. That is S 1 devotes discrete facilities to each 
of its large account client’s works. The people in such dedicated facilities work as an 
extension of the client’s facilities. The company has a dress code, that is relaxed on 
Saturdays. The building of the offices most often visited was shared with many other 
firms as well. The premises of the offices were not really impressive. Starting from the 
building’s entrances, to the lobbies of the floors on which Si’s had its offices. On one 
of the various floors of the offices there would be a receptionist who handled the 



visitors and all phones. The receptionist also handled other sundry jobs like contacting 
the travel agents etc. 


5. 1.1.5 Organization of SI 

The vice-president of SBU 1 explained about the organization of S 1 (See 

.Figure 5-1). He explained the available ways of grouping as per the businesses in 

which S 1 was involved. 

1 . Technology : in terms of Mainframes, objects, system software and application 
software. 

2. Market wise 

Geography: Europe, USA, Far-East. 

Vertical Domain; Finance, manufacturing, service, and health care. 

Large accounts. 

1 . Functional : Human Resources, Finance, Operations Support. 



He said that they have reorganized recently to be more customer focused. But they 
have almost all of the above groupings at the corporate level. The SBU’s are market 



.Figure 5-1 SI Corporate Organization Chart 

based. “The functional (Human Resource Management, Finance etc.) and technology 
divisions are central resources. Our policy is to go for greater market share in the long 
term. With a customer focused, resource constrained organization”. 

The division of work to the SBU’s is based on the size, operational area, and the 
experience of the SBU Head. 


















5.1 .1 .5.1 Development Group Structure: 



Figure 5-2 SI Large Account Structure 


The offshore manager explained about the structure in one large account inside the 
SBU 1. The functional stmcture of this account is shown in the Figure 5-2. He 
mentioned that he was able to give so much time as currently the client was in the 
planning phase and “business is rather slack nowadays. The client’s business cycles 
drive our work cycle”. He himself had 12 years of total experience in the industry and 
had been in the current position since the last one and half years. This account had 
about 100 dedicated people — 75 offshore and 25 onsite. The offshore work was 
mainly maintenance, and new development. There was only about 20% analysis work 
done by SI. 


He mentioned that the other SBU’s had similar stmcture in terms of offshore and 
onsite managers etc. “The actual organization of the project team depends on the size 
and nature of the project” (An oft repeated statement through out the study). He said 




















that some of the Module leaders were handling 2 projects with one or two persons in 
each. There were projects where there were 2-3 Module leaders under the supervision 
of a Project leader who in turn reported to the offshore manager. 

In case of insufficient people within the account, members as necessary were requested 
from the central Manpower Allocation Group. This group has the full information 
about the manpower requirements and availability status company-wide and shift’s 
manpower or requisitions Human Resource Management group to recruit new ones. 

The onsite manager is supposed to look after business development with the client, 
handle potential problems, and manage the onsite group. He is a person with at least 8 
years of development experience. The onsite team member is actually working for the 
Project leader of the client. All the team members assigned onsite only after the client 
has approved them. And their client’s comments have a large role to play in career 
progression. 

The offshore teams are organized in the same manner as the client’s organization. In 
this case, the client has functionally organized it’s software teams, and this is reflected 
in the offshore team organizations. There are 8 dedicated teams according to domain. 
An example was given where the onshore team is called the finance team, and worked 
solely on developing financial software for the client. 

Work Discretion: The outputs of the team members are fixed with respect to time and 
task work. The member is free in deciding actual solution(algorithm) of the problem. 
The members are rotated to a different area (project), typically after 18 months. The 



assignments depend on the qualifications. The assignments tend to be among the 
project groups within the account. 

The offshore manager gets support from the central services like Human Resource 
Management, Operations Support, Administration etc. 

Later the deputy of the above offshore manager was interviewed 

He was called Module leader, alternately as the Process leader. He looked 
after the marketing of one client project and looked after the logistics of 
another project. He also served as the Backup or Deputy Account Manager 
in the absence of the Offshore manager. 

He has technical responsibilities as to the planning, monitoring and developing 
the modules assigned to him on time and with acceptable quality. He often 
sits in the reviews with the clients for the projects or the planning stages of 
the modules. 

He had the following points to make about the hierarchy of the company and the job 


rotation. 



Promotion is more in terms of financial incentives. 

One’s designation changes, but not necessarily 
the work content. He showed the designation 
hierarchy of SI (see Figure 5-3). This was not 
the latest formal hierarchy after the 
reorganization. This is different & varies from 
the SBU organizational chart as that chart 
emphasis the role to be carried out. General 
Manager upwards, the work is more 
administrative — ^planning, budgeting, 

promotions, etc. then development related. 

“The client is possessive of the project team members, and rotations are not 
easily approved.” He said that such large account clients have a large say in 
the manning of the teams. 

The quality control and assurance group is under the Vice President, Technology and 
Quality. This group was found to be manned by only 3 people dedicatedly. Also, these 
3 people were there on a rotational basis for about 2 years. That for the span of their 
posting, they were to handle only the quality aspects of the company. They managed 
the quality training to be done, they looked after the process of acquiring and 
maintaining the ISO certification etc. The current person handling the quality group 
said that most of the quality nitty-gritty was handled within the development groups by 
the Quality coordinators. These coordinators did not belong to the quality group, but 
were some persons from other projects. “We are only facilitators”. The primary 



Figure 5-J SI Designation 
Hierarchy 




responsibility seemed to keep track of the revisions and releases of the quality manuals. 

The Human Resource Management group, the finance group, the administrative 

groups, the operations support groups were all organized in a 2-3 tier hierarchy. 

Horizontally, each of the groups had about 3 or more specialization’s. 

5. 1.1. 6 Size 

At the time of the data collection, S 1 was about 1300 person strong. 

• The Human Resources Department group was under severe pressure at the 
time of the visit. There were just about 4 people looking after the Human 
Resource Management affairs. There were supposed to be about 8 people. 
The finance group totaled about 15 persons. The operations support group 
looked after the infrastructure and administrative needs of the organization. 
These include the receptionists, the secretaries, the network maintenance, 
purchases etc. These were about 100 people at the most. The Quality group 
incharge said that there were only 3 people, on a rotational basis. The 
technical division was estimated at about 100 people. 

• The rest of the personnel were in the SBU’s. These were the people 
involved in providing the service and software development. Among these, 
there were different groups varying in size. For example the large account 
group visited, had about 100 people. There were accounts with just 5 
people. 

5. 1.1. 7 Summary 

• SI shows very few people in specific marketing assignments and in the 


support groups. 



S 1 shows a dynamic structure in the development groups. That is there is no 
fixed assignments except the project roles that are for the duration of the 
project. The role of the project leader could be taken up by any competent 
fellow with whatever designation 

Hierarchy in designations does not reflect into much changed responsibilities in 
the development groups. Depending on the projects, the roles played by the 
same person can change. They are grouped on the basis of clients within the 
SBU. And within the client groups, they follow the clients structures in the 
large accounts or according to the size and number of modules to made in 
the project. The other support departments show more definite structures. 
They also have more fixed work responsibilities. 

The organization was overwhelmingly populated by the development involved 
tasks. It is a huge organization and bureauractic to a certain extent 

5.1.2 The Company S2 
5. 1.2.1 Introduction 

S2 is the software development division of a joint venture information technology 
company. The primaries are an Indian business house and an a multinational 
information technology giant. The joint venture has interests across the information 
technology spectrum. For example, it has a software product division that market’s the 
multinational’s products in India. S2 offers development and support services on a 
wide variety of platforms, particularly IBM mainframes. It provides systems 
integration, application development, conversion/migration and software support 
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projects. The head of S2 was from the foreign parent. The revenues were around Rs. 
30 Crores. 

5.1.2.2 Market & Strategy 

According to the vice-president, who headed S2, the primary customer of S2 was the 
multinational parent abroad. S2 was only recently semp and was planning for a major 
ramp-up of it’s service operations at the time of the visit. S2 was going in for more 
diverse customers than just the parent affiliate. Both abroad and domestically. 
Generally, the senior managers of the development groups and the VP decided how to 
grow the business. 

5. 1.2.3 Impressions 

There seemed to be some problems among the top executives. The investigator was 
kept shunting between with each saying the other was available. By the time of this 
writing, the two have gone seperate ways. And S2 is undergoing a tough time. A 
number of employees have left the firm, including a lot of people at the top. And its 
expansion plans are currently on hold. Given the visible lack of cohesion among the 
person visited,, the investigator was not surprised at the downmm. 

S2 has its offices dispersed in 2 places in its home city, with one of the above 
mentioned executives at each of the sites. It was planning to open another development 
center in another town. The building visited housed the office of the VP of S2, the HQ, 
and also, one of the development centers. S2 had a dress code, generally along the 
lines of its foreign parent’s traditions. The premises of the offices could be called 
“swank”. The security was noticeable. The entrance had electronic security systems. 



5.1.2.4 Organization 

The corporate organization of S2 is based on a mix of market and technology (see. 
Figure 5-4). The clients from the parent’s divisions, come to them mostly based on the 
technology skills they seek. According to the Vice President, the team members are 
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not really fixed in a particular group. They are moved as the need arises. The core 
analysts remain with their respective groups always. They actively head the projects or 
for bigger projects, work under more senior managers. There are 12 people dedicated 
in quality. 


The marketing department is split, according to customer set or geographical basis, 
about 2-3 people per section. These are account managers who manage the back office 
























once the projects come in from the customers. These account managers are 
technically competent. With about at least 4-6 years experience in development 

The functional groups like support departments like Human Resource Management 
and finance had stable, definite, 2-3 level hierarchy. The Human Resource 
Management group was split into recruitment + Personnel, and the training group. 

5.1. 2.4.1 Development Group Structure 

The development groups are organized according to the technology focus of the 
clients. All the groups internally are organized around Core analysts. These are like the 
project managers or leaders in other firms. There is a group head in charge of the 
development group. Below him are several core analysts. There are team members 
under the supervision of the core analysts. According to the size and nature of the 
project, the senior team members could be playing the role of module leaders. 

The core analysts are specifically attached to their respective development group. 
These have had more than 4 years of experience The team members are freely 
allocated to the departments as the need arises. These have had less than 3 years of 
experience. The quality groups help coordinate quality activities, but the review teams 
are from within the development group. 

5.1.2.5 Size 

S2 at the time of the data collection, was about 400 people strong. The marketing 
department had about 12 people. The finance and Human Resource Management had 
about 20 people. The Operations Support group had about 10 people. The quality 
group had about 12 people. The rest of the personnel were in the development groups. 



5. 1.2. 6 Summary 

52 has a functional marketing team. It shows very few people in marketing, and 
functional services. S2 has fixed structures in the functional groups of Human 
Resource Management, Finance, etc. The development groups are one pool from 
which people are allocated to which ever project requires them. The overwhelming 
majority of the personnel are development personnel. 

5.1.3 The Company S3 

5. 1.3.1 Introduction 

53 is a public limited company incorporated in India, with over 38,000 shareholders. A 
foreign body has an equity stake in S3. S3 is part of “India’s leading multi-million 
dollar global export group which has interests in IT, Engineering, Agro-chemicals, 
petro-chemicals and infrastructure projects” with presence in USA, Europe, Singapore, 
etc. S3 does conversion/Migration, downsizing. Software Re-engineering, software 
maintenance, applications development. It also has some agency operations to provide 
training for a foreign software product. S3 has shown spectacular growth since its very 
recent inception. S3 showed revenues of more than Rs. 60 Crores in 1995-96. 

5. 1.3.2 Market & Strategy 

S3 has executed more than 40 offshore projects for clients such as Singapore Telcom, 
AT&T NEC, etc. S3 will remain a service provider in the near future. It soon plans to 
establish 2 more development centers in different cities in India. It helped some clients 
establish virtual software factories. 

It is venturing into new areas like multimedia, telcom applications. Its traditional area 
is in manufacturing applications. Their senior people have had experience in these areas 



and they built upon it. The senior development managers and the CEO, and the VP set 
the strategies. Some of the managers say that a change towards products is imminent. 
They already have agency operations to market some products. They have some 
product like tools developed which are under limited use within the company itself. 

5. 1.3.3 Impressions 

S3 was most helpful in conducting the visit. There was a very professional air in all the 
transactions that occurred with every one. At the time of the study, S3 had one 
development center which also housed the administrative offices. It was the only 
service firm with all its facilities in one physical place. They had a company canteen on 
the premises. Every one from the CEO to the newest member and guests had their 
lunch there. There was a strict dress code similar to the other service companies, i.e. 
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the light colored sober full sleeves’ shirts and ties for the gentlemen. Saris or salwar 
kameez for the ladies. The premises, from the entrance inwards to individual desks 
were immaculately kept. There was a high technology security arrangement consisting 
of computerized time checking and video cameras at the receptions. Even the security 
guards had to be absolutely neat in their appearance and behavior. Except at the floor 
leading to the CEO’s office, all the other floors, the security handled the reception 
desk. He did not handle incoming or outgoing telephones. But visitors were 
courteously seated in a well maintained lobby, while the person to be contacted was 
called outside. The overall impression was of competent efficiency. 

5. 1.3.4 Organization 

Its organization stmcture is as in Figure 5-5. S3 is an export oriented unit and it 
created a subsidiary (S3_subsidary in the figure) solely for the domestic market. This is 
essentially agency operations to market products in India. 



The International Business Unit (IBU) are incorporated companies in the geographical 



Figure 5-6 S3 IBU Hierarchy 

sphere of operations. The primary function of the company operations abroad is 
marketing and onsite project coordination. The IBU were earlier called the sales 
offices. There are about 3-5 people at each of these offices. According to the vice- 
president, head of Corporate Service, totally, there are 10 people doing the marketing 
functions. All of these have been developers at some time or the other. These are also 
senior people as they have to coordinate the onsite developers. 

The Deputy General Manager, Projects explained about the difference between what 
he repeatedly clarified is the “Administrative chart” (See Figure 5-6) and the project 
structure. The former gives the designations and reflects seniority. The project 


structure defines the roles. 













5.1. 3.4.1 Development Group Structure: 

The project structure is as in Figure 5-7. The project structure is flexible, depending on 
the size of the project. There could be just a team member and a designated project 
manager in a project. This project structure is different for projects that do 
maintenance work. Such maintenance projects are about 30% of the business and are 
not ISO certified. 

Except the quality facilitator, the rest of the teams is dedicated for the duration of the 
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project. That means that the quality facilitator can be a facilitator for many projects 
simultaneously. The technical writers are specialists in technical documentation. These 
also could be part of different projects, if they are small (less work load). The team 
members are chosen from the pool with the Resource Management Group, who 
“owns” the team members till the rank of associate Consultants. There is another 
group called the Project managers Group, which “owns” the senior personnel. The 
team members undergo training when unassigned to a project. Generally the team 
members are allotted to projects according to the systems division. But occasionally 














projects arise that need to be filled in from other divisions. Hence attempts are made to 
multi-sldll the team members so that they can be assigned irrespective of division they 
belong to. The team members also could be assigned across IB U as of now. When the 
reorganization and the expansion process is finished, then there ought to be little 
transfers across the IBU (presumably by then the EBU’s will have been able to hire 
enough personnel and become self sufficient. Till then the personnel will be shared). 

5.1.3. 5 Size 

At the time of the study, the firm had a strength of over 600 people. 

1. The Vice President further informed that the company has 452 technical 
personnel, 75 fresh recraits, and the remainder are in support services. The 
quality function has always a dedicated strength numbering about 13, 
including some developers “loaned” to quality. 

2. Administration has a strength of 9 in a two tier hierarchy. The Third & 
lowest hierarchy level people are all hired on contract basis. These amount 
to 12 people on contract basis. The Human Resource Management has 8 
people in a 3 tier hierarchy, starting from a Senior Manager. The training 
group has 5 people in a 2 tier hierarchy under a senior manager. There is 
an R&D group that has 88 people. They are arranged as per the technical 
area. The support groups do not have shifting working arrangements like in 
the development groups. Nor are these other groups very big. 

5. 1.3.6 Summary 

S3 shows a flexible structure in the development groups, very few marketing 
personnel, and small support groups. The majority of the employees are in 



development oriented jobs. The designation hierarchy is not related to the work 
responsibilities, which may not change though the person may have a higher 
designation. The Human Resource Management and the training function are separated 
here. The supporting functional groups have fixed responsibilities. This company is 
unique from other service companies in that it has specialist technical writer. 

5.2 The Company PS1 

5.2.1 .1.1 Introduction 

PSl is a publicly owned company. It is a software projects and products company 
providing professional service in various parts of the world and domestically in India. 
PS 1 strength is in developing and implementing GUI and RDBMS based client server 
applications. PSl is a company in the process of shifting focus from projects and 
services to packaged software. It had revenues over Rs. 40 Crores in 1995-96. The 
company is proud of its relatively big investment in its R&D. 

5.2.2 Markets & Strategy 

PSl implements projects around the world and in India as well. PSl does : 

• Customized projects for exports & domestic operations. 

• Professional services for onsite. 

• Development, marketing and support of its own products. Particularly in 
financial areas and manufacturing. 

• Marketing and support of agency products. 

The company was a pure service provider until recently. Now the firm has an explicitly 
stated intent to move into the products development and marketing. It puts in about 



12% of its revenues into product development and R&D. The founders of the firm 
essentially decide the strategies. The decisions as to which projects should be 
undertaken or not depends on the senior development managers & the CEO within the 
SBU. 

5.2.3 Impressions 

The head office of the company are within the surroundings of an export processing 
zone. The office premises gave a well maintained neat look to it. In the same city, there 
was another set of offices outside the zone. These handled the domestic operations and 
were in sharp contrast to the head office. PS 1 has a dress code, relaxed on weekends. 
The employees were extremely cooperative in assisting in the study. 



5.2.4 Organization 
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PSl underwent a reorganization recently after which it is now reorganized into “a 
federation of market-based SBU’s”, supported by central services ( See figure Figure 
5-8). The idea is to be able to better address the needs of the customers in the 
countries of operations and to keep the feel of a Small company under the larger 


umbrella. 











PSl has about 8 full marketing offices in India. It has subsidiaries a,broad. It has 
development centers in 2 metro cities and a dedicated R&D development center in 
another city. 

The SBU’s for areas abroad are incorporated subsidiaries in the geographical area of 
operation. The SBU heads or the CEO’s of the SBU are stationed there. PSl has a 
local of that area as CEO in one of the SBU. The primary function of these offices is to 
get contracts for offshore development, get the short term contract programming 
assignments, and to coordinate and manage the onsite personnel. These SBU teams are 
small in number. These people who 
primarily do marketing functions “need 
experience in IT, so that they can 
understand the client’s requirements” 
informed one of the marketing 
executives. This person himself had 
about 8 years of development 
experience. The country manager 
(exports) for one of the SBU’s talked of 
his job as providing “support to the front 
end”, “back office work like 
coordinating estimate communications 
to the front end, providing them sales 
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data, brochure etc.” His experience in 
development was about 8 years. 





5.2.5 Development Group Structure 

PSl projects structures are flexible depending on the size of the project (see fig. Figure 
5-9). 

The Project Manager appoints the Quality Control-in-charge(QC), the Quality control 
team and a delivery coordinator, from amongst the project team itself. The QC is 
among the more experienced of the developers. This person, for the duration of the 
project is involved in this role. The QC team itself may be made from the developers 
among the different modules, they will be doing dual tasks of development as well, 
when not called for the reviews. Similarly, the module leader holds the dual 
responsibility to develop the user and technical manuals. The developers are assigned 
from the “bench” or “float”, that is the unassigned developers, and from projects that 
are almost complete. Till the resources of the SBU’s grow, the SBU’s share all the 
facilities. They are expected to develop their own facilities. Then, each will have their 
set of “float”. Thus, only for some time, the developers would continue to be assigned 
for offshore projects to any of the SBU’s irrespective of their parent SBU (A situation 
similar to S3). The kind of project they are assigned depends on their experience, 
training and the needs of the project. When not on projects, they are supposed to be 
training. 

5.2.6 Size 

The company has a strength of over 700 people. Of the over 700 people in PSl, over 
100 are on assignments abroad at major multinationals. Totally, there are over 475 
qualified technical personnel. 



Its Indian operations are by far the biggest of aU its other operations, in terms of 
number of people. The Indian SBU is about 275 people. The Indian operation has an 
intricate organization. A major component of it force is made of marketing and support 
for its product operations. This amounts to about 150 people. There are about 40 
people providing support services to the units of this SBU. Most of which provide 
administrative support to the field teams. 

PSl’s Central Corporate Service groups total to 44 people. This includes a handful of 
people in the very recently formed Project Services group, some of which are technical 
people. These support the Foreign market SBU’s. 

The other support departments like finance, quality, human resources 
department/Admin. have more definite working arrangements. They are also less 
required to perform multiple duties. They also are arranged in a 2-3 level hierarchy. 
They are very small in number e.g. Quality, under a GM is planned to have only 3 
dedicated people. Each of the three has a specific and fixed role to perform. 

5.2.7 Product Organization 

The product development center had an organization totally distinct from the rest of 
the development groups. The development groups of the SBU’s had no other fixed 
divisions or groupings besides their SBU. The product development teams were 
organized on the basis of the products developed (see Figure 5-10). The size of the 
application development teams was very variable. Sometimes they were sent out for 
product support. Or were engaged in maintenance of earlier versions. The testing, 
groups were smaller and almost constant in size. The persons here were not needed to 



provide support for the product and stayed at the center. There was rarely any cross 
over between the testing groups and the development groups. 

There were 4 people from central services to provide support to the development 
center. The quality guidelines were followed during development and the testing teams 
were to ensure a higher level of quality requirements that are a must for products 
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informed the GM, Product Development. 

The development of the product was carried out as a project. The strucmre of this 
team was very different. See fig Figure 5-11 The importance of testing and review is 
obvious. The primary reason for this is the greater need for quality in products. 


informed the GM. 














5.2.8 Summary 

PS 1 shows great differences in its Service 
oriented organization and in the product 
oriented organization. While the service 
wings show flexible organizational 
arrangements that vary as per the 
projects in hand, the product operations 
have stable organizations around the 
products developed. The product development organization has specific testing teams 
that are separated from the development teams. In ther service operations, the reviewer 
is doing developmental work as well. 

• The functional support groups have fixed work and a stable hierarchy. 

• The Ratio of the personnel doing market related activity in the Indian SBU 
is dramatically different from the export oriented SBU. This is a direct 
reflection of the primarily product orientation of the Indian SBU. 

5.3 The Product Companies. 

5.3.1 The Company PI. 

5.3.1. 1 Introduction 

PI is a single product, privately held company. The company had revenues of over Rs. 
10 Crores in 1995-96. 

5.3. 1.2 Markets & Strategy 

The product is an accounts and finances management software. The Indian domestic 
market is awash with similar products but this product had some innovative features 
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that made it very popular. It has been bought by a wide spectrum of businesses from 
multinational companies, big corporate houses, to smaller retail shops, small scale 
sector companies, etc. It has sold over 7000 copies and even is being exported to the 
Middle East and the South Asia. 

The Chairman and Managing director set the strategy. They are committed to its 
product. It will continue to enhance it to match its market’s requirements. They have 
no intentions of diversifying into related products. According to the trade literamre PI 
had plans to set up a subsidiary company to take up the marketing of the product. 

5.3. 1.3 Impressions 

The branch office coordinators, the administrator, the dealer manager, all seemed to 
have a lot freedom to carry out their duties. There seemed to absolutely no dress code. 
The people were well dressed, but not appearing really formal. Some employees, who 
normally were not required to attend field calls, were less formal. They sometimes 
made small forays for documents, barefoot. The offices had a well maintained, sober 
look to them. The office was in a very up-market mall type location. 




Figure 5-12 PI Corporate Structure 


53.1.4 Organization 

The company is a family concern. A Chairman heads it’s structure (see figure Figure 5- 
12). As a policy, the company has no designations at all. “Yeh mera kaam nahi hai, 
Aisa, kisine nahi kahna chahiye” (No one should be able to say, that this is not my 
work)” said the Chairman. “Saab ko saab kaam karna hai” (Everybody has to do all 
kinds of work) he elaborated. Therefore, the company has no official organizational 
structure. The figure is constructed by the investigator. The effective structure is flat— 
everybody reports to the Chariman for all matters except technical. The chairman was 
kept informed about all decisions taken. The person handling the administration had 
been in the company since its inception. And he reiterated this view of no positions and 
designations, except for the accounts section. He also said that every body did 
whatever the work was to be done. This is the view from the top management. 

The impression gathered from the employees is different. Every employee seems to 
have a primary work assignment and secondary assignments. One of the members 
contacted said that his primary work is to look after the dealership network. The 
secretary mostly handled the files pertaining to the purchases. The production handled 













the copying and dispatch of the physical package. The receptionist handled calls and all 
the communication requirements such as fax, keeping track of who is where and 
making travel arrangements, etc. She also provided customer service if she was free. 
The person the investigator labels as ‘Administration’ seemed the only person without 
any explicit primary functional responsibility yet seemed to be attending to all small 
conflict resolutions and gave commands. This person also seemed to handling a lot of 
calls from outside regarding matters that pertained to the mnning of the company. For 
example, there was a call regarding a new computer to be installed, this person handled 
the negotiations; there was something about the deliveries of floppies for the 
packaging, something regarding the buildings at a branch office, etc. The branch office 
coordinators also seemed to describe their work and view themselves as branch office 
coordinators, inspite of no designations. That is there was a great deal of division of 
work duties. Their secondary duties generally meant answering customer queries. 

The most frequent activity seen at the office was handling the customer queries. 
Everyone at the office seemed to handle the customer calls. The receptionist could do 
it, but if busy, the call was passed on to any one free to take it. This included the 
Chairman, except the 3 people in accounts and the 2 in production. The investigator 
was informed that they also were fully capable and trained to take customer calls if the 
load is too great. But generally they were not required to do so. 

The only work divisions that officially were acknowledged was the accounts, the 
production and the titles of Chairman and Managing Director. No one else had any 
designations, including the people in accounts. 



Every body seemed to report to the Chairman and only for real technical difficulties or 
training duties or legal matters was it that the managing director seemed to be 
required. AU the day to day management was handled by the ‘Administrator’ and the 
Chairman. Every body said that they reported to the Chairman. 

The company had branch offices in 2 other parts of the home city. These were mn by 
the branch office coordinators. They looked after everything there, from management, 
customer service, day to day matters dealing with the administration of the site etc. AU 
the records of the transactions were forwarded and kept with the Head office. The 
company had two outstation employees. These were in different metropolitan cities 
and handled all the market development for those regions. They also reported to the 
chairman every evening by phone. 

5.3. 1.4.1 Development 

The managing director alone seemed to do all the development, made the manuals and 
gave the initial training to the dealers, company personnel for the new releases of the 
product. There were 2 people whose primary task was testing and quality assurance. 
They tested the product thoroughly, before it was released. They also were the first 
ones to learn the product and aid the MD in training the others. The most difficult 
queries from the customer were handled by these people. There was no one else in the 
firm besides, the MD and the 2 testing persons who was involved in the development 
related tasks of the product. 

5.3. 1.5 Size 

According to the branch office coordinator, the company strength was around 30, the 
dealer coordinator thought it to be near 50. The ‘administrator’ and the chairman 



agreed it was around 25. The company has about 25-50 employees (depending on who 
was giving the figure). There may be a legal subsidiary formed to do most of the 
marketing of the product but whose operations may have been integrated with the 
operations of the parent company (Dataquest,1995 pg.l65). This could be the reason 
for the discrepancy in the figures. 

5. 3. 1.6 Summary 

PI depicts an emphasis on marketing of the product in its organization. Everybody 
provides customer service. Except for that, every body’s work is specialized. 

The development work is all carried out by the MD, but there are specific people to 
carry out the testing function. 

5.3.2 The Company P2 

5.3.2. 1 Introduction 

P2 is a division of P2 industries. This company is part of a respected, diversified, more 
than Rs. 600 Crore business house. The business house is into yam, cement, 
electronics, etc. P2 is expected be hived off as an independent company soon. P2 is 
into high-end segment of software generically called as enterprise resource planning 
systems. P2 also sells some datacom related products. If s major product is its offering 
for the enterprise resource planning systems market. It achieved sales of around Rs. 10 
Crores in the year 1994-95. 

5. 3. 2. 2 Markets and Strategy 

P2 develops and markets its own products worldwide. It has subsidiaries in its major 
markets of North America, Europe and the Asia Pacific to sell and support its 



products. It has over 25 sites already established world-wide. The customers are 
primarily large manufacturing firms. 


A ‘Apex Board’ of aU departmental heads and the CEO form the strategy making 
body. The company is committed to its ERP product. It will continue to enhance it and 
improve its technology. There are plans to make products that cater to the entire 
enterprise. 



Figure 5-13 P2 Corporate Structure 


5. 3. 2. 3 Impressions 

The offices of the firm were very spread out. The head offices and one or two 
development groups were in one building, the other development groups were 
dispersed in 3-4 other scattered buildings. Some of the other buildings were visited 
during the visit. All of the sites had a very functional & comfortable look. They were 
not badly kept, but they also did not have expensive furnishings, floorings, etc. There 
was a dress code. Particularly, the sales staff had to follow it more strictly. The offices 
did not have a frenzied air that the other firms seemed to have. The technical service 


















desks showed a greater lack of time. The product teams seemed have complete 
freedom as to their products. 

53.2.4 Size 

Currently the company has a strength of around 700 people. Out of this, about 150 
persons are involved in support activities like Human Resource Management, Finance, 
Facility, Training, etc. The quality group is about 10-15 people. The training group is 
about 15-20 strong. Human Resource Management is about 10. 

About 200 persons are into sales, marketing and customer related activities like 
installation, queries etc. The Indian sales team is about 35 - 40 people while the 
installation team is about 100 people. The business analysts are about 35. The 
marketing & sales teams at the subsidiaries are not part of the above figures and are 
separate. 

The remaining 350 odd persons are into the development activities of the various 
products. The firm is not dominated by the developmental personnel. 




Figure 5-14 P2 Partial Hierarchy 


53.2.5 Organization 

P2 is viewed as a company organized around products. It consists of a set of 
departments, as shown in the figure Figure 5-13. The department heads report to the 
CEO. Figure Figure 5-14 shows the hierarchy. Each of the products is supposed to do 
its own development and sales. Out of the companies stable of products, the most 
important product is it’s ERP product system. This is a large system. And thus an 
elaborate organization to handle its development, sales and support exists and makes 
up for most of the company’s people. The other products are not so vast or 
complicated. Nor is the organization required to develop, sell and service those 



























products. The focus was on the ERP product that made up most of the organization. 
As can be seen, there are different teams that are involved in the sales and the 
development. 

53.2.6 Development 

The ERP product system has a number of modules, each of which can be sold as an 
individual product. Each of these modules has a group dedicated to its development 
and maintenance. Figure Figure 5-15 shows the organization of the product 
development departments. Each development department consists of many 
development groups. Each group, headed by a product head, works on one or more 
identified software projects. There may be more than one project associated with each 
product. For example, while a previous version is under maintenance, the next version 
would be under development. Each group generates the product requirements, 
develops the product, gets it accepted and carries out product maintenance, if 


applicable. 



The product champion here gathers the requirements for the product, together with the 
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product head. The development group then goes ahead with design and development 
of the product. 

The size & nature of the product decides the size and breakdown of the team to make 
it. The sizes of the product teams vary. Once decided, there is little variation in the 
team structure or composition. The developers and other team members are 
encouraged to stay as long as possible with the product. Midway transfers to other 
products are discouraged. Some transfers are allowed if the developer has spend more 
than 2 years on the same module. In the new module, the developers take about a year 
before they start contributing to the product. 

Even after the product is into sales the maintenance work goes on. When work on the 
next version starts, it is preferable that the people working on the earlier version are 














available to work on this new version. The work content is fairly fixed and stable. The 
developers are never in touch with the customers. Technical specialization is 
encouraged. 

At P2, the product’s quality is in the hands of the product team itself. Under the 
guidance of the quality department, the quality functions are supervised by the product 
Champion and the product head. There is an external product audit team those checks 
for compliance’s with the quality systems. Other wise, the programmers within the 
product group look after the reviews, low-level testing etc. External system level 
testing is carried out by a separate department. 

5. 3.2.7 Sales & Marketing 



Figure 5-16 P2 Sales and Installation Structure 


P2 has an elaborate and a distinct organizational setup to carry out the sales of the 
ERP product and its installation (see fig. Figure 5-16). The sales & implementation 
department is headed by a GM. The department carries out 2 functions. The sales 
function and the installation function. The Business Analysts and the Technical services 








do the actual installation. The installation process is taken up as a project. The 
Business managers do the sales functions. There is a small amount of customization 
done to the ERP product which is done by the technical services, in a project mode 
with the Business analysts doing the requirements for the project. Thus these teams are 
fluid and short lived. They exist for the customization and then reform for the next 
assignment. The new team may or may not have any of the former members. There are 
subsidiaries abroad which look after the sales and implementations abroad. In India, 
the sales function are organized as per the geographical regions of the country — North, 
West etc. Each of the regions is to have its installation team. The team doing the sales 
and installation is totally different from those doing the product development. 

There are special desks that are meant to handle customer queries. These are organized 
on the basis of the region they serve. The programmer in the product development 
never has to handle any customer query. The desk or the Technical services handle all 
customer complaints that arise. 

5.3. 2. 8 Support functions 

In P2, the customer training is handled by a separate Training department. This handles 
not only the internal technical training but also customer training. The Human 
Resource Management group takes care of recmitment and personnel. They also do 
non-technical training. These people have fixed stable tasks. The quality department 
does the standardization of the quality processes. The quality groups sends its 
members as key members of the external review and audit teams of the products. The 
support functions have elaborate 2-3 layered hierarchy such as the training (See fig. 


Figure 5-17). 



53.2.9 Summary 
The most prominent feature 

of P2 is specialization and a 
well defined, clear cut 
hierarchy. The development 
groups are also fully 
elaborated, with stable structures and fixed work allocations. So are the sales 
functions. Sales and installation are totally differentiated from the development groups. 
The top management drove the product development process. These consisted of the 
departmental heads. 

The marketing, sales and installation teams were not insignificant in numbers. The 
development personnel were not the overwhelmingly majority as observed in the 
service companies. 

5.3.3 The Company P3 
5.3.3. 1 Introduction 

P3 was created by its parent organization as its prime technology vehicle with vertical 
specialization in providing state of the art information technology solutions to the 
financial services industry worldwide. The parent is one of the world s premier 
financial institutions. Revenues of P3 in 1995-96 have been around Rs. 30 Crore. 

Among its products, it has a product targeted at corporate banking. This is a large 
system, that can take about a year to install. This includes the time taken to train 
people and the initial systems studies. The products are based on best practices around 
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the world and occasionally, the banks have to modify their operations to conform with 
the product’s methods. It has products in the mutual funds business. And also product 
in the retail banking segment. The firm also provides IT services for the financial and 
banking sectors. Services like customized software, business and technology consulting 
etc. They also have some products related to software quality and projects 
management. 

53.3.2 Market and Strategy 

P3 markets its products through 7 branches in the Asia pacific region, Africa, Middle 
East, Europe and the US. 

The parent body has influence on the strategy of the firm, given its history. The CEO 
and the senior managers do the planning. P3 lays a strategic importance on its 
packaged software with more than 50% of its current revenues coming from its 
banking and financial service products, mostly through exports. And more is targeted 
for. 

5. 3. 3. 3 Impressions 

The company did not seem to have a dress code. People could be seen in casual wear. 
The Head office was located at the far end of an alley, and not prominently placed. The 
exterior was not impressive. The lobby was more functional then the interiors, which 
were well furnished and kept. 

5.3.3.4 Size 

The organization had a strength of 450 people at the time of the visit. There are about 
12-13 people in the Human Resource and training group, about 7 persons in the 
Quality group. There are about an average of 10 persons in each of the support groups 



of Finance, Administration, etc. The figures at the overseas branches number around 
70. The majority of the workforce are in the development and installation groups. 
Followed by the marketing & support groups, mostly overseas. 

5.3.3.5 Organization 

Figure 5-18 shows the corporate stmcture of P3. According to the Asst. General 



Figure 5-18 P3 Corporate Structure 

Manager -Human Resource & Training, P3 is organized around market segments and 
support services. He also referred to the market segment groups, ITIG and the Quality 
groups as the ‘technical groups’ and the rest as the non-technical groups. 

The market segment groups are the: 

customized software segment represented by the ITIG group which also 
doubles up as the installation and implementation group. 

The corporate segment group 


The retail segments group. 

















The Quality Group which develops software quality products and also doubles 
up as the quality control and assurance group for the rest of the firm. 

“We have little hierarchy here”, according to the Assistant General Manager (AGM)- 
HR. The firm sees itself as a flat organization. Though there exist different 
designations there are only 4 categories among the personnel, called as grades A to D. 
Grade D consists of the group heads & senior consultants who are mostly technical 
experts designated as Project Managers etc. Grade D has some minor stratification for 
Vice President or CEO level of executives. Grade C which consist of the consultants, 
with titles like Managers or Project leaders etc. Grade B is the entry level for the 
developmental and professionals and they are called associate consultants. Grade A is 
for the non professionals in the firm. And applies only to the support functions staff. 
He said that that the business minded personnel rise faster and can go to the top. 
Otherwise, they plateau as technical managers. Generally promotions are more in terms 
of financial rises rather than changes in grades or hierarchy. 

The international marketing group takes care of the marketing of the product. The 
regional offices overseas take care of sales and customer queries and problems. 

5. 3.3. 6 Development 

Within the market segment groups, the personnel are organized on a product or 
project basis. The structure of the product group is a reflection of the product 
architecture. The ITIG implements the customized segment projects, & installs the 
products. ITIG installs the product on a project basis. At ITIG, the same group goes 
through the whole project from start to end. Whether the project is a customized 



software or a product installation the structure of the projects and the product 
development groups is similar (See figure Figure 5-19). 

Depending on the size of the projects, the structure varies. The structures and the 
numbers are not so variable in the product groups. Some times personnel are lent to 
the implementation teams. 

The testing functions for the other products are carried out by the personnel from the 
Software Process Management Group (SPMG) group. They also facilitate the quality 



Figure 5-19 P3 Project Structure 
review processes during development. 

5.5.3. 7 Support 

The personnel in the support groups have less flexible or diverse task allocations. For 
example the Human Resource & Training group. The location managers coordinate the 
training or the Human Resource development at the various developmental sites. The 






















quality groups develop their own product line and also provide quality guidance to the 
other development groups. They carry out the testing of the products. But the quality 
personnel are always into quality. They do not go out on field assignments. The 
administration carries out the facilities maintenance activities as well. Their lowest level 
labor is contracted out. 

5.3. 3. 8 Summary 

P3 shows specialization with a difference. The requirements — for both the products 
and the customized software projects, are generated with the help of the domain 
experts. The quality group making a product for software quality is another example of 
domain experts developing the requirements for the product. The development is of 
the products is done by different groups and the installation by another group. Yet, 
some members of the product development groups can be sent to the installation 
projects or some of the customized software projects. 

The product groups are organized by their products and then by the modules as per the 
architecture of the product. The ITIG group is based on projects at hand. 

The testing is done by the quality group. And they also have their own product. 

The support functions are stable and with standard responsibilities. The 
marketing & sales groups are not negligible in numbers in comparison with 


the development groups. 



Chapter Six 


6. Data - II : Across the Firms 

6. 1 The Generation of Requirements 

6.1.1 Across Case Observation Summary 

In the software service firms of SI, S2, S3 and the service wing of PSl, the client was 
the initiator of the software development process. The client was the source of the 
requirements. These were in the form of completed requirements’ documents or at 
least were outlines. In all the service firms, the managers highlight the client’s role as 
the final arbitrator of quality. If the client’s requirements are met, the software is 
accepted. All the service companies’ development processes required customer sign- 
off, before the next phases began. 

In case of the product companies, the requirements were generated within the 
company. The management was the initiator of the software development process. 
What seems to emerge from the product companies is application domain expertise to 
develop the requirements of the products. The companies displayed familiarity with the 
application domain of the product. They have domain experts — either temporarily 
hired consultants or employed within the organization, who are instrumental in 
generating the requirements. 

The importance of feedback affecting the requirements also emerged. All the product 
companies acknowledge acting on feedback got from the customers, consultants etc. 
The feedback was most often channeled from the sales teams. 



6.1.2 Case Excerpts 

6.1.3 Service Operations 

6.1. 3.1 The Company SI 

At SI, the offshore manager for the large Account of SBUl (Strategic Business Unit 
1) explained that the client’s project manager supplied the requirements. This was the 
starting point for the assigned offshore teams to develop the software. The manager 
said that the actual process of conversion of the requirements to the software was left 
to the offshore team. But it had to meet the client’s approval. 

The client manager was the final arbitrator of deciding if the software was not 
acceptable at any stage or not. Besides the formal progress reports, the client would 
occasionally clarify points or the teams would request for some if needed. Each stage 
or milestone of the development was cleared by the client before the next stage was 
progressed to. 

6. 1.3.2 The Company S2 

At S2, the foreign parent’s division generated the requirements. The s2 development 
teams then developed the software, under close coordination with the client divisions. 
The head of Quality of S2 has the following to say “Ultimately the client decides if the 
work is of acceptable quality. Thus his intimate and active participation is invited in the 
development process. This way he can be fully reassured about the work quality. 

6. 1.3.3 The Company S3 

At S3, the Deputy GM of IBU Europe talked about their elaborate 11-13 stage 
development process. The process starts with the customer calling for a proposal from 
S3, given his needs. S3 develops an estimation. The estimation is easier if the detailed 
requirements are available or else it involves some system study to develop some 



workable requirements on which to base the estimation. Typically, the requirements 
document was available from the client. Then S3 started with the software 
development phases. At the end of each phase, the customer had to accept and give the 
go-ahead for the next phase. The process culminated with the installation, sometimes 
with a maintenance contract. 

6. 1.3.4 The Company PSl 

The service wing of PS 1 also showed a similar process to S3. The process begins with 
the usual request and estimation process. Generally the client gives the detailed 
requirements. After the negotiations, the contracts are signed. Then subject to reviews 
and approval of the client, the stages are implemented. The client satisfaction decides 
the quality. If PSl ’s quality processes clear the code and the client disapproves (a very 
rare occurrence), then the work has to be redone, subject to the contract’s agreements. 
Sometimes the work is done using the client’s quality processes. 

The PSl GM of Quality, had the following to say on quality “In projects, quality is 
easier to achieve — you have one client, about whom you have complete information 
available, a controlled environment. Product quality is a more difficult issue. You have 
no definite knowledge of the user. The percentage input of information that contributes 
to high quality is less. Therefore your quality procedures need to be more mgged for 
developing products. Quality is thus many more important to products than to 
projects. In projects, satisfying the client means you have achieved quality.” 



6.1.4 Product Operations 
6.1.4.1 The Company PSl 

PS 1 has a well-defined process that leads to product development. It starts with 
anyone within the company, giving the proposal for a product. A format is suggested. 
This proposal is considered through many stages and committees before it reaches the 
stages where the standard development processes can be followed. The stages proceed 
through feasibility analysis, market research, etc. 

On questioning the head of the Product development center on the reason for the 
particular portfolio of products of PSl, he commented that “We had experience in 
those areas, our available manpower had experience in similar projects.” The 
traditional areas of PS3 before they began product development have been 
manufacturing, financial and insurance. Their product portfolio is a reflection of this 
experience. 

The product’s wing of PS3 employs external consultants to help develop the 
requirements for its products. Not much information was forthcoming but the gist is 
that the product teams work together with the consultant for some period and develop 
the requirements. The consultants are used for their knowledge of best practices, 
experience and domain expertise. 

PS 1 uses other sources of requirements also, but they are not formalized according to 
the GM. He agreed that this is something they need to formalize. But informally, it is 
through the feedback sources: the engineers that go occasionally are required to go to 
the field for installation customization or to deliver product training, the sales 


engineers, etc. 



6.1.4.2 The Company PI 

At PI, the Chairman was asked how they were able to come up with such a successful 
product. In his answer he elaborated a lot on his family’s traditional occupation of 
trading. In such a background, the children are expected to calculate and keep 
accounts from a young age. He then described his work experience in the accounts 
departments of various companies, before he setup his business. He said that the 
principles do not change, the accounting standards and practices rarely change. The 
basics remain same — debit here, credit there. After explaining background information 
he said due to all this, he very well knew how traders operated and what they needed. 
He said that using his businessman’s philosophy he thought, “if you do accounting on 
computers, then use computers for accounting”. Implying that instead of replicating 
the manual procedures on the computer, let the computer do most of them. With his 
son, who had a grasp of computers, came up with the product. 

How do they come up with enhancements? He said that many times, the sales teams 
would pass on common suggestions or complaints, direct customer feedback, by 
following modem trends in technology like networking etc. and accounting needs of 
customers. He said that their package was initially designed for the small retail trader 
in mind. But the package now has many corporate users, including multinationals in 
India and exported to companies in the Middle East etc. For this they have to include 
some features that are suitable for corporate purposes. 

6. 1.4.3 The Company P2 

The parent group of P2 has several process-oriented manufacturing units. P2’s initial 
product offering supported only process base manufacturing methods and only now in 
the upcoming version will the ERP product support discrete manufacturing units. The 



head of one of the modules certainly believed that the corporate background of P2 has 
a role to play in developing the kind of software they have developed. Some of the 
parent’s firms were among the first sites on which the software was installed. 

As can be seen in Figure 5-15, P2’s development teams have a product champion. This 
designation irresponsible for generating the requirements. This person has to smdy the 
competitor products, the latest and best practices of his domain, new advances in the 
domain, new technological advances, etc. that need to be incorporated and extracts the 
relevant features to be incorporated into the requirements. This person also is expected 
to travel to the installations and gather feedback from the customers, gather feedback 
from the sales and installation team and any other source that is deemed suitable for 
the purposes. They also may enlist the help of relevant consultants for their wide 
exposure. 

The product champion is explicitly mentioned in the quality manuals as the internal 
customer for the module of his group. Thus, He is also intimately involved in 
scheduling the development, monitors the development, testing, the final approvals, the 
documentation development and even in the preparation of the product training. He is 
expected to tap the feedback sources for improvements and new features. 

6.1.4.4 The Company P3 

P3’s parent organization and sister organizations are exclusively in the financial 
sectors. P3 was specifically created to leverage the parent firm’s IT expertise in these 
sectors. P3 employs professional bankers as part of their product development teams. 
These persons “are aware of banking needs— how banks function internally, the 



business needs of banks, what services banks would like to be able to provide and 
manage them etc. and how best to automate them” said Asst. General Manager (HR). 

The role played by these persons, as described to the investigator is very much similar 
to that of the product champion in P2. He generates the requirements, approves of the 
product features, etc. He also goes to customer sites and collects customer feedback 
and does some analysis, attends professional meets to keep up with his field and 
incorporate these into the requirements. Very often these people are at the site while 
the, installations are on to gather feedback and look for improvements. None of the 
development teams involve with the customers, unless they are assigned on temporary 
basis to aid in training or installations. 

6.2 Integration of The Marketing Task With The Development 
Tasks. 

6.2.1 Across Case Observation Summary 

The service companies displayed few dedicated personnel for the sales and marketing 
jobs. Also, these people were not functionally grouped as a marketing department 
except in S2 (see section 5. 1.2.4 for the numbers and organization details). Typically, 
these persons were stationed abroad. All of these persons had had some years of 
development experience. These persons had technical responsibilities as well — to 
coordinate the onsite work. These persons also played the role of the onsite manager 
for the onsite assignees. 

Client interaction is not restricted to the marketing & sales functionaries. Every one in 
development could be interacting with the clients. The senior managers are definitely 
involved as they communicate back and forth for the development. Sometimes even 



the most recently inducted programmer could be involved in communications with the 
client, regarding the segments under this programmer’s care 

At the product companies, sales and marketing were two distinct groups of people. 
The sales & marketing persons were not involved in the development tasks and 
generally the developers were not involved in sales and marketing tasks For the 
greater part, the development teams are not exposed to the customers Occasionally, 
they may be called to give some training to the user 

6.2.2 Case Excerpts 

6.2.3 Service Operations 
6.2.3. 1 The Company SI 

At SI, the SBU head has marketing support in the form of a marketing manager There 
IS no formal marketing group besides this manager This marketing manager is typically 
stationed abroad in the domain of the SBU As far as the Large account is concerned, 
the onsite manager looks after business development in the account He coordinates all 
onsite work, looks after new opportunities, establish and maintain relationships with 
clients and monitor customer satisfaction He typically is a person with 8 years of 
experience, about 2-4 of which have been in development 

At SI, the quality manual lists coordination of onsite work as one of the 
responsibilities of the marketing manager (See Section 5 1.1 5) This necessitates 
some development experience Offshore, the project managers are charged with timely 
deliverance of the software and acceptable quality and obtain customer acceptance 
This involves numerous meetings with the client starting from the initial estimation 


processes to the final delivery 



According to the marketing manager, the client (the client firm’s project leader in this 
case) can call up any team member if the client has any problems with some module 
developed by the member in question Typically the quenes are routed through the 
module leader or the leader of the project But often it happens that the client directly 
calls up or communicates with the team members In one issue of in-house journal of 
SI, there were some glowing examples of how some large accounts grew from 3 
onsite assignments to 100 person strength The client also honored some of the better 
performing engineers, who are now in more senior positions m the account Elsewhere, 
in the same issue the profiles of some of the very high executives are given One of the 
executives was portrayed as having contributed a lot to the growth of one account In 
the CEO’s message, he highlights the fact that SI depends on people who “enjoy 
building relationships” 

6.2.32 The Company S2 

S2 was the only firm with a specialist marketing department Though it was implied 
that the pnmary task was more of a liaisoning with the customers There were about 2- 
3 people per technology group And “they have to be technology literate” “Delivenng 
actual client satisfaction and ensuring repeat business lies in hands of the project teams 
through their work quality” according to the VP This because the project leaders have 
to understand what the client really wants and give the estimates And then they are the 
ones to fulfill the estimates. 

Here also, the client could interact with any one if needed The marketing people 
mainly took care of the business ends of the interaction The project teams delivered 
the technical solutions to the problems of the client. And the client could be requested 



midway m case of any clarifications or he could want to make some clanfications to 
the developers. 

Thus at S2, the imtial and later business interactions are handled by the marketing 
department. The technical interactions with the client are handled by the development 
teams 

6.2.3. 3 The Company S3 

S3 IS organized as per geographical market area The offices catering to these regions 
have about 3-5 people These function pnmanly as sales offices The SBU is 
incorporated as a company m the area of operations The sales people handle the 
accounts, grow it, act as liaison offices to the Indian offshore teams. They coordinate 
the onsite work as well. They have had some years of development expenence, 
otherwise they will not be able to realize what the customer desires This was stated by 
one of the managers He added that no one with less than 2 years of development 
experience was sent abroad 

The techno-commercial head of the European operations conceptualized the 
operations as marketing and using sblls. He said that the process of developing 
customized software involves “a heavy customer engagement process, from the sales 
personnel, to the CEO, development managers do the lowest level of programmers” 
Some times the customers also come down to see the facilities, etc before signing the 
contracts He elaborated that the quality and timeliness of the software are the 2 most 
important cntena for which outsourcing to India occurs. These he said is in the hands 
of the development teams and their managers And these ultimately decide if the clients 
are satisfied or not Thus at S2, interactions with the clients encompasses almost 
everyone in the development area.77ie Company PSl 



The service wing of PS 1 tacitly acknowledges the marketing role of the developer. The 
senior marketing manager, of about 6 years of development experience explained 
about the origins of most offshore projects He stated that most of the offshore 
projects had their origins in the 4-8 months contract programming jobs. These initial 2- 
3 assignees are persons with over 2 years of experience. Often, these people, have 
spotted opportunities for growth and informed the higher company officials On further 
directions, these persons discuss the possibilities with the client. “If these people have 
been able to favorably impress the client dunng their stay that plays a great role m 
convincing the client to try out PSl ” This typically results in bigger contract 
programming jobs Gradually the clients are convinced about the companies technical 
capabilities Then they trust the firm enough to outsource bigger projects offshore 
Commenting on this process, the Country manager explained “the customers are 
hesitant to give out projects, unless the company is known better ” The marketing role 
of the developers is clear 

Very much like S3, the service wing of the PSl operates with an organization around 
geographical markets Each of the SBU’s has an office stationed abroad that does the 
sales tasks The managers in PS 1 conceptualize the sales as front office operations with 
the offshore software factory as the back office operations. There are a very few 
people stationed abroad as part of the sales office These persons also monitor the 
onsite projects They would have had not less than 2 years of development experience, 
typically about 4 years. 

Regarding client interaction, the managers said that it is unavoidable. That to some 
extent, the fresh developers can be “shielded” or “hidden” from the clients, till they 



have got more confident with the development tasks. Otherwise communications with 
the client are a “part of life” in customized software development, according to them. 
The Country manager-exports explained that the people who are on the fast track 
(people with suitable qualifications, and who show better marketing aptitude along 
with technical skills, nse faster Hence fast track) have been bnght to spot 
opportunities m their interactions with clients and thus nse faster They are also 
assigned to the offices abroad for some time 

6.2.4 Product Operations. 

6.2. 4.1 The Company PSl 

The products development center of PSl, has dedicated development groups for its 
own products The marketing & sales of all products are looked after by the SBU’s 
The development staff have no involvement in the marketing or sales functions The 
sales and marketing groups have no knowledge of the development of the products 

Among the SBU’s, the Asia-pacific and the Indian SBU’s do most of the product 
marketing These display a well developed sales organization (See the section 5 2) 

The development people have very lirmted customer contact They may be called upon 
to impart some training or to do installation They are not in a position to affect the 
sale of the product to which they are imparting the training as by this time, the 
customer has already bought the product 

6.2.4.2 The Company PI 

At PI, the managing Director is the one-man development team Almost everybody 
else in the company is involved in the sales and marketing of the product exclusively 
The Chairman and father of the MD is involved in the requirements generation, and 



there are 2 other people who test the product. No other persons have any thing to do 
with the development functions The daily sales, marketing and customer support was 
handled by the rest of the organization. And the MD had no other involvement m the 
sales and marketing 

The customer contact of the MD seemed limited. With every new version of the 
product, he imparted training to the company personnel. In an annual dealers 
convention also he imparted training For customer service, he was called for only 
when no one else was able to solve the problem And such instances were rare. 

6.2.4.3 The Company P2 

At P2, the sales and implementation team under a GM Sales, handles everything 
regarding the sales, installation and customer service of their ERP product The 
overseas subsidiaries are meant to do the same in their geographical areas The other 
product groups also have separate organizational setup to handle their sales and 
marketing 

The development teams of P2 have no occasion to interact with the customer. The are 
not required for training or customer support The do only development 

6.2.4.4 The Company P3 

At P3, the ITIG (see Figure 5-18) looks after the sales and implementation of their 
products P3 has 2 major product lines and each has its own product development 
teams P3 has an international marketing group that looks after the marketing aspects 


of the products 



The development teams are never called upon to do any sales or implementations or 
marketing activities They have very liimted customer engagement opportunities. That 
too m post-sales activities like customer training and some installation support. 
Customer service and quenes are all handled by the ITIG. 

6.3 Specialization Of The Development tasks. 

6.3.1 Across Case Observation Summary 

The service companies portray none to veiy little differentiation of duties among the 
development personnel Project structures are defined in terms of roles. There are few 
instances of persons who specifically are meant to fill the same role in any project. 
Generally the project teams take the project from start to finish. The analysis, design, 
coding, documentation, testing, installation, training and maintenance if any are all 
done by the same project team Outside support is asked for only in case of the reviews 
and quality audits of the project. 

The product companies display differentiation among the development tasks very 
clearly As elaborated on in the Section 6 1, the requirements are generated by a 
different group of people, who do only requirements generation The design and 
coding IS done by a different set of people A different set of people do the testing. The 
documentation of the product is apparently done by the developers in most cases A 
different group of people do post-sales, activities like the installation, customer 


training, customer service etc. 



6.3.2 Case Excerpts 

6.3.3 The Service Operations 
6.3. 3.1 The Company SI 

SI has a very small dedicated documentation group that provides training and 
assistance for the developers in their documentation tasks The documentation is 
actually wntten by the project team members The documentation group does not 
assign Its members to the projects 

There are roles in any project team Every project team has someone occupying that 
role, but in the next project someone else may be in that role S 1 has no other specialist 
groups or divisions that lends people to the projects 

Every project has a Quality Coordinator (QC), and an internal quality review team. 
There is no group that provides Quality coordinators to all projects The project 
manager chooses the QC from his project team, generally a senior, expenenced 
developer Each project also has an external review team. Just as some members of this 
project are on the external review teams of other projects, members of other projects 
are review team members for this project There are no members who are only on 
external review teams. Except the QC, everyone else is carrying out some development 
or design or project management tasks as per their experience and roles For the 
duration of a project, the QC may not be doing any development In case of small 
projects, the QC could be doing other tasks as well 

The department of quality just aid, in the quality processes, just as the documentation 
group aids the documentation process Ultimately, the project members do the 


documentation or quality reviews. 



When the software is developed members of the team are assigned to do the 
installation and user training. Some of the team members are retained for maintenance 
and the group members are disbursed to other projects or are sent into training in 
anticipation of upcoming project requirements 

All of the development personnel belong to the pool of development staff, or project 
managers of the SBU and do not have any other specialized, departmental attachments 

63.3.2 The Company S2 

According to the VP, the only permanently assigned development people are the core 
analysts who permanently belong to the technology groups Otherwise the team 
members are freely assigned to which ever group that is shorthanded They are given 
training as per anticipated needs and if needed As the team members gam experience, 
they settle down in one of the technology groups as core analysts But till then they 
could be playing different roles The same team saw through a project from the start to 
the finish From initial estimates, analysis, coding, documentation and maintenance if 
required Also, if required, installation and training 

As m the case of SI, except the senior, core analysts, no other developmental staff 
belongs to any particular department 

6.3.3.3 The Company S3 

S3 portrays some specialization of developmental activity (see Figure 5-7 for the 
ensuing discussion) Every project has assigned to it a Technical writer. These 
technical writers are meant to carry out the documentation activities of the project. 
The technical writer could be part of different projects also, but is always doing the 


documentation tasks 



The quality facilitator also is a specialized role. This person is always from the quality 
group. This person also could be simultaneously part of different projects, but always 
IS the quality facilitator of the project. 

The test team leaders and members are dedicated to the project, but for the duration of 
the project. In the next project, they could be developers That is they are not in the 
test team role every project 

The project team does all the phases of the development activity from the analysis, 
design, coding, testing, documentation (with the technical writer) maintenance and 
post development activities like installation, training etc as needed 

6.3. 3.4 The Company PSl 

After Its recent reorganization PS 1 has decided to specialize some duties These mainly 
pertains to the expenenced people These come under the Project service group PS 1 
project structure has an independent role of the solutions architect (see Figure 5-9) 
This person is to provide assistance in the requirements analysis & specifications 
stages Most likely these people are to have had considerable experience & expertise in 
executing particular kinds of projects These architects can be serving more than one 
project simultaneously Similar, but as yet unimplemented is the role of the technology 
specialist This role will be like the solutions architect a expert, but in some 
implementation technology domain rather than the application domain Both of these 
experts could be on multiple projects simultaneously 

The project manager appoints people to the roles of Quality in charge, the quality 
control team, the Delivery coordinator, and the configuration in charge These are all 
well defined roles but people filling these roles will not be playing these roles in all 



projects always. For different projects, different people could be filling them, while 
some other time could be developing The module leader has specific responsibility to 
look after the preparation of the user and technical manuals. 

The same project team does the analysis, design, coding, testing, documentation and 
also installation and training duties For maintenance, some people retained within 
project or could be later on recalled in some cases. 

6.3.4 Product Operations 
6.3.4.1 The Company PSl 

PSl’s product center displays specialization in many places. The company employs 
external consultants to develop the requirements PSl’s product development teams 
are organized according to the product they make and the members are not freely 
switched between products There is a separate testing group and a separate products 
support group Each product team has a separate testing team assigned to it from the 
testing group. Members of these teams do not change places like the shifting of roles 
and duties in the service operations. 

The product teams do their own design and coding and documentation The test teams 
from the testing group provide testing The product teams also do the maintenance and 
revisions of the product The SBU sales teams do the marketing and selling of the 
products The product groups provide product training to the SBU sales teams in their 
respective products This team is distinct from the development teams. 

The product teams are sometimes called upon to do some installation of PSl’ s ERP 
product Then some of the members are deputized to the task. The other products 
installations are simpler and can be accomplished by the sales teams of the SBU. Each 



of the product has a product support group that takes all queries and problems from 
the customers regarding the products. 

The product operations of PS 1 show more stability and constancy of roles and duties 
then the service operations of PS 1 . 

63.4.2 The Company PI 

PI, though did not have designations, they certainly had a clear division of 
labor. At PI, the requirements were done by Chairman and the MD The 
design, coding & maintenance was done by the MD, perhaps, also the 
documentation There were 2 people who did testing 2 people did what 
was called the packaging. This essentially was making of copies of the 
product for distribution The installation and customer support was handled 
by the rest of the organization (see Figure 5-12) Customer training was 
done by the sales persons and dealers Dealer training was imparted by the 
MD and the testing groups 

6.3.4.3 The Company P2 

P2 evidenced more differentiation than any of the other companies Each 
product and product module had a dedicated development team to it. 
People were not freely moved from one group to the other. The 
development groups did the design, coding, product level testing, and 
maintenance As explained in Section 5 3 2 6, the requirements generation 
role was specialized by the product champion A documentation division 
created all the user and technical documentation, with input from the 
concerned developers and associated people A specific group did system 
level tests There was a special section of developers who created the 



lowest level software entities that were common across all of the ERP 
modules The sales and installation teams did the installation. Separate 
customer support groups took care of customer service through the 
overseas subsidianes and from headquarters also. The user training was 
handled by the training department The developers were not all called on, 
to aid in these activities. 

6. 3. 4.4 The Company P3 

At P3, the development teams were organized according to the products lines The 
development of each of the product lines is at different development centers The 
differentiation is as below. 

Each of the products had its own development team The development teams 
did the design, coding, and maintenance Requirements generation for each 
of the products was a specialized function. A separate group does the 
installation and implementation The persons who do requirements 
generations are part of the liaison team while installation is going on The 
product developers are called on to impart training to the users 

• The customer support services are carried out from 7 regional centers 
around the world 

The juniormost of the personnel, the fresh developers do only coding, and reviews of 
each others coding The module leaders supervise their coding efforts and are involved 
in individual programmers designs and the coordination of the programmers modules 
and programmers The project leaders, and the module leaders are the ones doing the 



design of the software. The project manager, and project leader and occasionally the 
module leaders, are involved in the analysis The project manager is looks after the 
project management activities. Customer satisfaction is primarily the responsibihty of 
the PM Thought the PL and ML have their own customer satisfaction responsibilities. 
In all these activities, the people are not specialized The activities could vaiy as per 
the size and importance of the projects. In one project, the programmer himself could 
be canying out everything independently if allowed. In another, the module leader 
could be doing project management activities 

6.4 Staffing Requirements 

This section explains the patterns of staffing requirements found in the companies 

6.4.1 Support 

6. 4.1.1 Summary 

All the software companies studied, showed similar staffing patterns in the HR, 
Finance and systems support areas The work m these areas is like in any other 
company, with specific & standard personnel requirements and available educational 
profiles 

6.4. 1.2 Excerpts 

The finance dept is staffed with accountants, MBA-fmance people. The HR dept is 
staffed by MBA in Labor or Personnel Management and MA(social work or Personnel 
Management) The systems support personnel are typically Electronics Engineers, 
some with added Netware training certification Some are computer engineers with a 
penchant for systems Sometimes ITI personnel, are employed, to do the minor 
hardware maintenance functions They are cheaper, than the more mobile systems 



engineers. This also frees the heavily loaded engineers for more critical tasks The 
Administration dept, has no specific recmitment requirements for the entry level jobs. 
It IS sufficient for them to be graduates. The administration looks after functions like 
reception, telephones, infrastructure facilities like canteens, tea, electncity, desks, etc. 
All the companies studied handed out the housekeeping & security to contractors. 

All the companies studied showed very little secretanal staff. Typically only the senior 
executives have allotted secretanes and often, are shared among executives or 
performed multiple duties 

The major focus of the study was on the staffing of the marketing and development 
functions. Here the following patterns emerged 

6.4.2 Marketing 

6. 4.2.1 Summary 

The pnmary difference among the service and product firms studied was the 
requirement of technical experience'* for the marketing people 

The product firms did not emphasize technical experience In the service firms, it was 
mandatory On the other hand, the product firms required formal education in the 
application domain; e g P2 required MBA (Production), PI required commerce 
graduates 

6.4.2.2 Excerpts 

The service firms studied, deployed personnel with significant years of development 
experience (at least 4 years). Preferably, with higher educational qualifications. So far. 


'* Technical expenencc here implies expertise in computers and software 



experienced developers only, go to the SBU on marketing assignments. It is not clear if 
under the new organization this practice will continue. The senior managers indicated 
that they would expect the next generation of personnel to be MBAs’, besides the 
technical expenence There are very few marketing personnel stationed at the offices; 
around 10-13 at the most These people also look after the coordination and guidance 
of the onsite developers, and this is another reason for their experience. The service 
wing of PS 1 was again similar to the others in having experienced developers assigned 
to do the marketing These assignments seem to play an important role for the top 
positions, as could be surmised from the profiles of the Sr Managers. 

In the Product companies, the marketing function has particular work force 
requirements According to the product being sold, the marketing personnel are 
supposed to have formal qualifications in those areas, e g P 1 required their marketing 
persons to be commerce graduates In the words of a senior person there, “... they 
must know how accounting is done How else are they to understand what the 
customer is talking about We can only tram in how to accomplish accounting 
procedures using computers and our package ” , P2 hired only MBA’s in their sales 
dept and were deployed according to the match of their specialization and the module; 
P3 employed professional bankers for the liaison with customers The product 
operations of PS 1 required a separate team for the marketing, most of which were 
MBA (Production). In none of the cases were these people expected to have technical 
expertise about computers and software, other than the product training they got. 



6.4.3 Development 
6.4.3.1 Summary 

There is some difference among the hinng of the development personnel at the entry 
level. This is the educational background of the software engineers in the core product 
development teams All software companies understandably prefer computer science 
engineers BE (any branch)+MCA is the next best profile The product companies 
prefer expenenced personnel to have had relevant exposure to software development 
related to the domain. 

6.43.2 Excerpts 

The service firms studied, took in people irrespective of their educational 
qualifications Thus anyone cleared by the recruitment process is acceptable. These 
processes focus on aptitude of the person. Thus the investigator met 
MBA/M Tech/M Com/B Sc /BE/B Com/MCA as well the NUT diploma holders and 
combinations of the list, among the developers Higher formal education is an 
advantage in promotions & on-site assignments. Almost without exception, the senior 
managers had professional postgraduate qualifications 

The product development groups of P2 and P3, seemed to be populated only with 
engineers As a person from HR in P3 said, “we take only engineers, for their supenor 
analytical abilities” The GM for the product group of PSl, commenting on the kind of 
people he expects . “ system programmers, people with analytical ability, creativity, 
flair for lower level programming, and an attitude that does not seek immediate 
results” It was a rare person with a non-engineermg background among the product 
groups This too is possible only if they had relevant experience in domain of 



application In one group at P2, only computer science engineers were taken. This 
group developed some cntical parts of the software 

The product installation groups of P2, P3 & PSl operated similar to a service firm, 
working on a project basis. P2 took MCA’s, MBA’s and NET diplomas m this 
function The MBA’s were the analysts, the other two kinds were put m the technical 
services of the region P3 permitted MBA’s m their installation groups. PSl sometimes 
borrowed people from the service wing for the installation group. 

P2, P3 both employed application domain experts for the job of the business analyst^ 
These people were part of the product development team and their job is to scan the 
available academic literature, evaluate competitor products, trade journals, trade 
technology, seek customer suggestions, observe the business processes, etc. Then, they 
generate the requirements for the product’s next version PSl sought outside 
consultancy for this purpose. In general, people who fill this slot, are experts in the 
application field of the product, typically either have field experience or are doctorates 
in that field, with some technical training 

For people above entry level, the service companies are glad to take in anyone with 
over 2 years of experience Their educational backgrounds are not so important 
Product companies take the experience holders only if they have had experience in the 
relevant area. For example, P3 takes in expenenced people only if they have had 
experience developing insurance or financial software At P2, a manager, (with 
significant experience in the manufactunng sector) from a service background, was 


^ This usage of the term business analyst here is to denote his knowledge of the business processes of the 
domain the term is not meant to convey the designation of business analyst 



inducted at a senior position. He was inducted, not m the product group, but in the 
installation group, that operates almost like a service company 

In the product firms, P2 for example, one product head remarked that though 
developers are allowed to transfer between product groups, they are expected to stay 
in one group for at least 2 years “It takes at least a year before they start contributing 
actively One has a lot to pickup about the product, besides the technical matters” she 
said. A manager in S3 said “ on-site assignments are allowed only after completion of 
at least 2 years of development offshore”. The statement that “At least 9 months to a 
year must pass, before we can recover the costs of training the fresh recruit” was 
reiterated often during the study. 

Then there is the matter of customer acceptance, particularly in the Service firms This 
comment by the training manager of S3 succinctly states it “ The customer will not 
accept any employee-types with less than 2 years experience and especially the Asia- 
Pacific region, of non-engineering backgrounds What really counts is the absorption 
capability In experienced people, the depth of experience is seen ” 

6.4.4 Training 
6.4.4.1 Summary 

There is a marked difference in the training patterns of the service and product firms 
studied The product companies include formal & regular training on the use of their 
products, that is completely lacking in the service firms The service firms all have 
programs for non-technical training especially communication skills 



6.4.4.2 Basic Training 

Almost all the companies studied, have a common induction program that is given to 
any new comer to the company Typically it is of around 3 days. Here, the company’s 
philosophy, business goals, departments, and more importantly the basics of the quality 
system of the company are introduced The senior executives of the firm address these 
sessions 

In the service companies, the fresh development recruits undergo about 2-6 months of 
training. In SI, there is a 10 day common training for all the developers, after which 
SBU group to which a fresh recmit are allocated, takes over the training. In the service 
wing of PSl, the fresh recruits are sent to an external training agency for 6 weeks. S3 
has an 8 week common training, then specialized training as per the division allotted 
All these training’s are mostly fully technical A small part of it is effective 
communication skills, personal effectiveness, etc 

In the product companies, besides the technical training, the fresh developers undergo 
training specific to the product group they are to join This include the internals of the 
product and how-to-use training All of PI, the Installation groups of PI, P2 & PSl 
are trained in the usage of the products This training is redone everytirae there is a 
new version. Since all of PI undergoes product training, anyone can provide customer 
support and installation More importantly, this frees the sole developer from the 
training task, as they m turn tram the dealers, customers etc. P2 and PS 1 have some 
common training for all the developers, on some internally built modules, that are 
common across their products After this, as per the product group they are allotted to, 
they undergo training on that product. P3 has an intensive standard training schedule 



after which the departmental training takes over who give the product training. The 
product wing of PS 1 has a technical training, including training on the usage of the 
internally developed tools Then the allotted product group’s training is undergone. 
Vendor/customer training is an important aspect of product companies training 
schedules The product development group in PSl does the product training to 
vendors, customers 

6.4.4.3 Continuos training 

Continual training occurs in the companies visited. All the companies have around 10- 
14 days per annum per employee, reserved for training. This includes the senior 
managers as well (But it was commonly noticed that their actual training falls short of 
the 10 days) That means that an employee has to spend around 2 weeks of formal 
training sessions There is a lot of informal training going on among the development 
groups These take the form of lectures of the special interest groups on their 
particular specialized technical topics S3 has such special lectures for Sr managers as 
well They have a program once a month for the sr managers where there is at least 
one presentation on an area of common interest, video presentations on culture of 
various countries, quality, etc 

In the typical continual training process, the project/product head sponsors the names 
of the candidates for training This is done after discussions with the concerned 
developer, in concordance with the objectives established dunng the annual appraisal, 
and the expected needs of the group/project/SBU. Sometimes the HR itself 
recommends people for training, dnven by company-wide requirements, and the 
profiles of suitable persons 



Across the studied service companies, there is lot of focus on communication skills. 
Not only is it part of the Basic training, but also features prommently in the continual 
training programs PSl often has external faculty ( professional consultants) take 
sessions on presentation skills, wntten skills, verbal and non verbal skills. SI has 
periodically occurnng such courses, referred to as the inter-personal programs At S3, 
during the project work that the recmits have to make, they are expected to make 
frequent presentations. 

Then there are also regular courses on management skills These are for vanous levels, 
depending on the number of suitable candidates and corporate needs The project 
supervisor recommends to low level management skill courses, if there is or going to 
be a need for such skills within the project. Requests for non-technical training are 
easily acceded to. On the other hand, the technical courses on newer topics, etc. are on 
a need basis. 

All the service firms studied maintained a detailed record of the skill levels of their 
employees The training details are used for manpower planning. 

There are some examples of non managerial and non-technical courses' PSl & S3 both 
had courses on Corporate etiquette These were mandatory for those being sent on-site 
assignments S3 also mns language classes, for the Europe &. the Asia SBU’s 

In the product companies there was a noticeable lack of emphasis on communication 
skills In the product wing of PSl, sponsorship to the corporate wide, HR dnven 
communications skill’s courses was generally not often The HR Training manager 
remarked on the absence of the product personnel in such courses Such courses are 



not seen as important by the managers there. This was sharply contrary to the service 
wing of PS 1 

P 1 had no concept of such training, nor did it have any other training needs except 
product training. P2 has had plans to implement “the HR training”®, but were not 
earned out till the time of the study there. The training courses available there were 
either technical or product The developers are sent for technical training only, unless 
the developer is to change product groups’, in which case the developer had to 
undergo the required product training The sales group, which actually sold & installed 
the software underwent product user training, and the usage of the technical tools 
needed to make modifications for installation 

6.4.4.4 Training for other functions 

The other support groups, such as the systems support, HR, administration had no 
special training programs available in any of the firms studied Only in PSl, anyone 
could be sponsored to the non-technical courses S3 mentioned training for the finance 
cell, which was for 4-5 days only The business analysts (the doctorates/domam 
experts) do not require training, though they may opt for non-technical courses or 
external training in their fields Each of the firms had one small special group that 
performed the equivalent of R&D for the firm This had its own training needs that 
were satisfied internally 

The product marketing groups needed no other profession related training. They 
underwent just the product user training The service marketing persons would have 


^ At P2, the training division took care of all the training needs The HR dept took as its responsibility to provide 
the ‘development’ courses such as personal effectiveness, communication skills, presentations skills etc 

’ P2 allowed developers to move into other groups after a minimum of 2 years in one group 



been through sufficient non-technical & management training as developers. This is 
one reason why they are eligible for an on-site assignment. As mentioned earlier, S3 & 
the service wing of PSl had some special courses for those going for on-site 
assignments abroad. 

The senior managers in all the firms studied underwent management training suitable to 
their work profiles, to fulfill their compulsory training time. 

6.4.4.5 Faculty 

Across the firms studied, the faculty for most of the courses were persons from within 
the company itself Only PS 1 had an external agency do the standard training for its 
fresh inductees. The others went for external faculty only when unavoidable S3 had 2 
resident faculty, for a foreign firm’s product that S3 was using internally & later plans 
to market (this is highlights the need for product training for marketing purposes). This 
was because S3 did not have any person within the company familiar with the tool. 

The faculty for the fresh graduates would be persons with about 3-4 years’ 
experience The non technical courses were often given by the executives 
Management courses for the lower levels were always given by the executives The 
training foLthe senior executives is sometimes given by management consultants or 
very experienced customer’s managers (m case of service firms) are invited speakers. 

Across the firms, the faculty for the training were in-house This places a great burden 
on the development people who anyway have deadline pressure, particularly m the 
service firms. Yet this is seen by the management as a necessary task and no one is 


allowed to shirk for long 



“ It takes some time rounding up faculty to take the training courses” said the PSl 
technical training coordinator. At PSl, the float® who have had about or more than 3 
years of experience are expected to involve themselves as faculty or in special internal 
projects or be under self-training under the supervision of the Technical training 
coordinator In S3, the involvement in training programs is seen as an advantage in 
appraisals The students rate the faculty and this rating is added to the person’s 
database P2 lists employee development as a management competency area. P2’s HR 
keeps records of the faculty’s performance as well as the students 


In PSl ,the pool of unassigned developers, who are in-between assignments are called ‘float’ or ‘Bench’ 



Chapter Seven 

Conclusions and Learning’s 

This chapter analyzes the observations from the cases \vith respect to our framework. 
Then conclusions are drawn and the suggestions are based on observations 


Parameter 


Software Service Companies 


Software Product Companies 


I Organization 


1 Organized around the markets 
served 


1 Organized around the products 
developed 


2 Numencally, developers m 
overwhelming majonty, with a 
minority of support staff 


Development groups are not 
stable, Vanably organized, 
depending on size & nature of 
projects 


Numerically developers not in 
overwhelming majonty, 

Support staff is accompanied by 
dedicated marketing staff, 
which IS a sizable strength of 
the company 


The top development managers 
play dominant role in deciding 
strategy i e what kind of 
projects can be taken up or not 


Development groups are stable; 
Organized around 

products/product’s architecture 


Everybody in development 
groups, m contact with 
customer, besides the people for 
sales etc 


Top management, not 
necessarily composed only of 
development managers, decide 
strategy. 


5, 


Only specified employees in 
customer contact. Not necessary 
that they have development 
experience 


II Source 

Requirements 


of 


Client drives the development 
process No development occurs 
till client initiates the business 
cycle And development ends 
when the client is satisfied that 
his requirements are met 


No apparent role of application 
domain knowledge affecting 
the choice of clients sought 


Top management dnves the 
development process. 

Development continues in 
terms of improvements, 
irrespective of customers. It is 
the management that decides if 
the software is ready for 
release 


Client hand 
requirements 


down the 


Evidence of top management 
familianty with the domain of 
application of product. 


Sign-off at every stage is a 
must The software delivered 
has already most of the 
feedback the customer could 
provide There are no new 


Special, domain experts 
develop the requirements 


Feedback from customers affect 
the requirements of the next 
version/release of the product 






Parameter 


Software Service Companies 


Software Product Companies 



ni Integration 
Marketing 
Development 


releases, only new projects 


(but not compulsonly)* 


10 Few personnel explicitly 10 Dedicated distinct groups, each 


dedicated for marketing tasks 
They also have some technical 
duties of on-site coordination 

1 1 Client interaction happens with 
all levels of development 
personnel 


for sales & marketing and for 
development Division of 
technical duties within the sales 
groups 

Client interaction almost 
exclusively the domain of a 
sales and implementation team 


IV Differentiation 
Development 
Activities 


12 No major differentiation 
evident Same team earned on 
from start to finish 


12 Specialization most evident in 
the requirement generations & 
testing tasks & installation 


V Human Res 
Requirements 
Training 


Resource 
mts & 


13 Recruitment of freshers for 
development or marketing is 
not differentiated 

14 Engineering educational 

background preferred But if 
aptitude IS displayed, any 
educational background topped 
with some computer courses 
will do 

15 While allocating manpower to 
a project, the client has a say in 
the staffing of the project 

16 During Appraisals, the clients 
input is also considered 

17 Regular training courses for 
interpersonal communication 
skills & other non-techmcal 
training are available Besides 
the technical courses 


13 Different recruitment processes 
of freshers for development and 
marketing as also for the other 
groups 

14 Particular about the educational 
background of recruit 

a) for sales & requirements 
generation education should 
relate to the product 

b) For development 

engineenng students 

15 No involvement of customers in 
placement of recruit into 
development group 

16 Customer input does not count 
in appraisals 

17 Pnmanly, courses on product 
training and technical training. 





The table above summanzes the observations from the cases. The table indicates the 
differences that emerge among the product and service organizations We now analyze 
the evidence with our respect to our hypothesis’s 

The Evidence 

Organizational Configuration 

From the observations, we gather the characteristics of the organization in software 
service firms. 

1 The service firms are overwhelmingly dominated by developers In terms of 
power and population The top posts are held by managers who have risen 
from the development ranks The support functions are very much in the 
minority population 

2. The top development managers can decide on what projects can be taken 
up or not. The support functions do not make business or operational 
decisions The top management is made up of people who have been 
project managers 

3 Service firms operate with projects These projects are executed in close 
contact with the client The client has to approve each stage. Satisfying the 
client by meeting the client’s demands and standards is of pnme 
importance The developers work with different clients at different times in 
different capacities They do not ‘belong’ to a particular department 
because there are no departments to work m, but projects The only 
departments visible are the support functions 



4 Everybody has to master the skills of software development before being 
given other responsibilities The software developer is more valued for his 
experience. The really important functions are performed by people with 
greater and greater years of expenence. 

5. The general impressions gathered and particularly the dress code, indicates 
that the service firms give a lot of importance to the appearance of the 
personnel, the looks of their offices etc 

Requirement Origins 

The service firms show an elaborate process that involves the client The following 
additional features are noted 

• the customer initiates the development process with a requisition for 
estimates The client provides initial requirements to base the estimation. 
Then the cycle of information exchange and software development starts 
No development occurs without clients 

• the client has to sign off the stages as they proceed. This calls for close 
involvement by the client. This way, nothing is implemented that the client 
does not approve off Everything that the client feels is required is 
implemented. It gives the client more control over the development 
process, to the client’s satisfaction It requires the client to provide the 
needs and to let the firm implement. 



• The firms did not seem to give much importance to the application domain 
knowledge The firms emphasized technical competency applied to a 
variety of projects 

Integration of the Marketing Task With The Development Task. 

Except one, all the service firms display geographical, market based SBUs. With the 

head offices of the SBU located within the region of the SBU The following points are 
clear 


• There are very few people allocated expressly to perform marketing roles 
These persons are stationed at the SBU overseas offices. They also have 
the dual roles of acting as the managers of the onsite developers They have 
little role to play once the development process is underway There, the 
client and the development team interact directly 

• All of these people have had about 3-4 or more years of development 
experience They need not be posted abroad for long duration These are 
plum assignments and all the top level managers have records of such 
assignments 

• Contact with the client occurs at all levels in the firm. It is not possible to 
isolate the interaction The clients like to monitor closely, sometimes the 


developers need more information 



• The people who rise speedily in the company have played a role in growing 
the business They are able to spot opportunities in interactions with the 
client. 

7.1.4 Specialization of Tasks. 

The service firms display a singular lack of differentiation among the people The roles 
exist in the project structure, but the people who fill them change each time. The 
employees of this project, in the next project could be carrying out different duties as 
assigned to them 

The same team carries the project from start to finish It is not as if different people, 
come and go, doing the same tasks in different projects 

7.1.5 The Human Resource Management & Training 

The service firms allow client influences in the placement of people in projects and in 
their appraisals They also show the following 

• Freshers are put into coding jobs An engineering qualification is preferred 

• Client intervenes in the posting of persons onto their projects Their input 
is also considered in appraisals 

• The training programs have a variety of non-technical courses besides the 


technical programs 



• The faculty for the training programs are the more senior operational 
people within the firm Participation in training programs is seen as positive 
input during appraisals 

7.2 The Analysis of The Service Firms 

We conjectured (See Chapter 3 ) that software service firms would portray a 
resemblance to Mintzberg’s “Professional Bureaucracy” (Mintzberg, 1979). Software 
service firms would show features that are typical of service organizations 
Coproducer role of the client, inability to separate the marketing from the operations. 
We now see how the evidence supports our framework 

7.2.1 Likeness to Professional Bureaucracy 

The organization of the software service companies into market oriented SBU’s, the 
prominence of a large, dynamically organized development workforce supported by 
small support departments, powerful project managers, closeness to the client etc. all 
point to Mintzberg’s organizational configuration of Professional Bureaucracy The 
following discussion irefers to Mintzberg, (1979) 

According to him, the key, dominating part of these organizations is the operating 
core, in this case the developers The operating core dominates and is supported by a 
small support structure The support functions are well elaborated hierarchies and little 
variation in tasks. The professionals in such organizations have considerable freedom 
and have no rigid structures or hierarchies In the professional bureaucracies. The 
professionals have to work directly with the client. They need the freedom to be able 
to satisfy the unknown and varying demands of the clients About the work of 



professionals, Mmtzberg says “Control over his own work means that the professional 
works relatively independently of his colleagues, but closely with the clients he serves ” 

The phenomenon of independent work is seen in these firms. The project is like a 
complete mim firm in itself, and has all resources within itself The projects are given 
the requirements of the client The client allows them freedom m the actual solution of 
the requirements, so long as he is able to trust and is satisfied with the solution The 
project in a software services does all the tasks from design, coding, testing, etc. for 
the client from within itself It operates independently of other projects 

Peer review Yet the projects are not totally independent The projects must depend on 
the other project groups in the firm for quality assurance “Professional organizations 
have standardized work but complex enough that it must be controlled directly by the 
operators who do it And the work can be judged only by similar operators.” As 
observed, the reviews of design, code, etc are all done by colleagues from other 
projects or other modules within the project. 

The associated parameters of professional organizations to a dominant operating core 
are the training and mdoctnnation of the fresh recruits Mmtzberg says “Training and 
indoctrination is a complicated affair in the Professional Bureaucracy. ..with long period 
of on-the-job training, such as internship in medicine and articling in accounting. Here, 
the formal knowledge is applied and the practice of the skills perfected, under the close 
supervision of members of the profession ” In software service firms, the on-the-job 
training and indoctrination appears in the form of the initial 1 5-2 years of close 
monitoring by the module leaders and team leaders. It is only after the 2 years that 
serious responsibilities are given to the person And the process of training is continual 



as the professional have to master new knowledge as it comes. This highlighted by the 
high amount of time ear-marked for training The senior members of the firm impart 
the training This leads to indoctrination and handing down of the culture of the firm 
and Its methods to the freshers 

The software industry exhibits apprenticeship nature that reflects a craft industry [see, 
Schware, 1990] Experience counts a lot in measunng the maturity of the developer 

This training period imparted to every one leads to a standardization of skills 
According to Mintzberg, the Professional Bureaucracy is relies on the standardization 
of skills ‘These skills are imparted under the close on-the-job training and 
indoctrination Everybody is thus aware of what needs to be done, and what to expect 
from the others This helps in coordinating the loose configuration without strict 
structures, rigid rules etc ” The software service firms depict the standardization of 
skills as everyone in the organization has had developmental experience The senior 
executives rise from the operating core, the marketing assignees are sent only after 
they have had some years of experience There is none in the operating core who has 
not had developmental expenence All except the minority support staff have 
development experience And these support staff never meet the client and instead, 
they provide services to the professionals 

In Professional organizations, the professionals form the administration The 
professionals not only make the administrative decisions but also the business 
decisions As seen in the software firms, the senior management are from the 
development groups. That is besides the support group’s heads, the Vice Presidents, 



the SBU chiefs, etc. have risen from the development body. They form the overall 
strategy making body of the firm. 

The prime examples of Professional Bureaucracies given by Mintzberg are craft 
production firms, personal service firms. Hospitals, public accounting firms etc. All 
examples taken from the service sector As the authors in Section 2.4 portray, the 
Indian software industry is mostly providing manpower in the form of coding services 
Brooks and others (See Appendix 2) have compared software development to a craft 
These features point to software service firms to display characteristics of Service 
organizations 

7.2.2 Likeness to Service Organizations 

The services nature of software service firms is brought out by identifying the 
distinctive characteristics of service organizations Intangibility of service provides 
incentives for service operations to make relations with service providers more 
satisfying to clients Service production requires the provider to extract or solicit the 
exact nature of the service to provided to the client This calls for being able to handle 
the client and know his needs Technical competence has to be displayed by the 
provider to reassure the client Thus one of the points is the need for technical and 
interpersonal skills on behalf of the provider. 

The simultaneous production and consumption of services leads to close interaction 
between the provider and the client. Thus the client is brought into the production 
process Thus the client is a co-producer m the process (Bowen, 1990) The close 
interaction also precludes the presence of a third party which can do the marketing 
Thus a separate marketing role is diminished. The client will give his business to the 



provider only if the provider seems competent So it is upto the provider himself to 
prove his competency. Here again arises the feature of technical knowledge as well. 
Thus we see that the above points are displayed by the software service firms 

7. 2.2.1 Technical <£: Interpersonal skills 

• The need for interpersonal skill the training programs m these firms lay 

equal emphasis on the improving interpersonal skills among the recruits 
There seemed to be a great emphasis on this. Some of the firms prefer to 
recruit people with better communications skills 

• Techno-social relationship feature — ^The people sent for marketing or sales, 
also, have to have development skills The developers are all expect to have 
interpersonal skills. This clearly shows that the personal have to be able to 
mange people and yet have to have technical skills This point is a feature 
that IS peculiar to service firms (Bowen, 1990). 

7. 2.2.2 Coproducer role of client in the software services business 

The software service firms clearly display the coproducer role of the client in the 

business. 


• Source of requirements- The client has to come to the service provider & 
give requirements before the development process starts 

• All service firms require the client to sign off each imlestone or stage before 
the developers move on to the next. This involves the client deeply in the 
production (development process) 



7.3 The Product Firms 


Here we shall summanze the observations of product firms. These observations are 
the features that make them distinct from service firms. 

The distinctive features that emerge from the study are. 

1 Differentiation. 

a) The software product firms have more, distinct task assignments then the 
service firms 

b) Distinction between the marketing sales & support from the development 
groups All the product fiims observed displayed this trait They had a 
distinctive, separate group that did the sales and marketing of their product 
Two of the companies also showed a different group independent from the 
sales team to provide customer support Another. (PI) did the customer 
support functions, but had no separate dedicated group for it. 

c) The development people were isolated from the involvement with the 
customers They did only the development tasks 

d) Stable development groups organized around products. Unlike the constant 

f 

flux in service companies, the development groups showed stability The 
personnel between groups did not change rapidly There were more or less 
permanent grouping around the products to be developed This was very 
much unlike in the service firms, where the developers really did not belong 
to any group 

e) Differentiation within the development activities 



i) Differentiation for Requirements Generation: The product 
companies show a presence of application domain specialists that are 
involved m the requirements generation of the products The job can be 
compared to a funnel This person filters all available information from 
the customers, consultants, developers, monitors competing products, 
etc and develops the formal requirements document Generally, this 
person is part of the development group 

ii) Development personnel In product firms, the developers did only 
development related tasks They were not involved in the sales or 
customer support tasks They did the design, development and 
documentation 

111) Testing personnel All the product companies have separate people 
to implement the testing functions They are in a group separated from 
the development group Unlike in the service firms, wherein the 
reviewers/testing is done by people from another project, these people 
are dedicated for test purposes only 

Self Generation of Requirements 

a) The product companies did not need some customer to start their coding 
efforts They generated the requirements by themselves The ability to 
generate requirements on their own seems to be linked to prior expenence 
& familianty with the domain of application Each of the product 
companies showed a history of business in the application domain, or the 
origins of the firm in the application domain 



Feedback Mechanism 


a) All the product companies showed the existence of a feedback mechanism 
The feedback from the customers affected the requirements generation 
process. None of the companies seem to have really formalized this 
mechanism Yet all the product companies seemed to be using this 
mechanism to incrementally improve their products 

Product Training 

a) The training activities in product firms showed extra training, that was 
absent in the service firms This is product related training All the firms, 
showed product related training to be a major component of the training 
program for the fresh recruits The sales and support staff was also given 
training when ever new versions of the product appeared. The developers 
typically gave the training Like the service firms, these firms had technical 
doamm training for its developers 



Chapter 8. 


8. Prescriptions, Limitations and Further Work 

“A software project is traditionally based on a case-by-case, problem 
solving approach; the development of strategic capabilities is based 
instead on experience reuse and organizational sharing 
Competencies must be built in ciritcal areas of the business by 
packaging and reusing clusters of expereince releveant to the 
company’s business” — Basili & Caldiera (1995). 

What can we now suggest from our study‘s Our study establishes the fact that 
software service firms are basically service organizations We can improve their 
management by applying the learning’s from the service literature 

8. 1 Prescriptions For improved Services 

From Bowen (1990) & Davidow (1989), we present some of the primary lessons for 
service management 

Inseparability Realize that service strategy, marketing, operations, quality and human 
resources management are very tightly interlinked The quality delivered depends on 
the quality of personnel “The process is the service” (Bowen, 1990) The service 
provider is also the marketer. A marketing or Human Resource Management strategy 
IS also an operations strategy simultaneously This is one of the most important mind 
sets to acquire in the improvement of the service business 

Focus The essence of service strategies lies in focus. This point is repeatedly 
emphasized in the service literature Focus on the kind of clientele, on the services 



provided Davidow (1989) emphasizes to classify the customers, not according to 
market, but according to the customer service segments Limiting the clientele to 
control supply and demand by focusing very sharply on the client types. Focus forces 
the organization to find ways and means to best serve the chosen segment It also 
allows the proper management of the complexities due to the inseparability of the tasks 
like marketing, operations, etc Focus will enable satisfying clients better than the 
competitors due to increased knowledge acquisition about these particular clients. 

Manage the Encounter Bowen says that service quality is generated in the encounter 
between the service provider and the client The location of the encounter, the 
“atmospherics” etc all count in building up the confidence of the client in the service 
provider. Train the personnel to be aware of this phenomenon and manage the 
experience that the client undergoes Since the service given depends on the client’s 
request for it, the best possible effort must be made to create an environment where 
the provider is able to elicit what the client really requires 

Manage the Customer’s Expectations The client is the ultimate arbitrator of quality. 
If he is lead to expect a lot from the company and the company fails to deliver, the 
client goes away with the impression that the company is not worth it According to 
Davidow, “lead the customer to expect slightly less than what the company can deliver, 
yet also deliver better & different from the competitors ” This point also highlights the 
need to understand the client’s requirements very clearly 

Manage the Service Provider Since the interaction between the service provider and 
the client is where the business is made or broken, the perceptions of the service 
provider greatly affect the business. The service provider is a crucial ingredient to 



success in the services business The service nature requires a rapport and good 
communication to develop between the service provider and the client The good will 
felt by the provider invariably is got across to the client. Investing in increasing the 
competence of the provider only serves to increase client confidence in the fums 
capabilities 

Continuos Improvement Bowen (1990) states that services are easily copied So for 
continued success, the service firm needs to continuously find ways to deliver better 
service at a profit to the provider which are different from the competitors. Bowen 
advises to develop advantages that are not easily copied. Such as developing long-term 
relations with clients, understanding the client’s business so well so as to understand 
the needs even if he is unable to properly elucidate them etc Improvement goes hand 
in hand with the policy of focus. 

8.2 Prescriptions for Evolving to Software Products From 
Software Services 

Yoffie (1994) observes the trend in cannibalizing in the IT industry The current 
business is cannibalized by the company, by utilizing the later technologies, processes 
etc How does one cannibalize a software service business? If we sell them a product 
instead of a custom built, “from-scratch built” software. 

Schware (1992) notes the global trend towards products He also notes the trend 
towards verticalization of the market “The software market has become ever more 
specialized by end-user sectors. This is because each sector has its own characteristics 
in terms of data processing expenditures, environment, level of information’s intensity, 
and importance of vertical applications.”(Schware, 1992 , italics ours) 



The above observation is the key to an evolution based strategy towards products for 
the currently successful service firms Effective service management demands focus. 
The observation above directs us to the kind of focus we should adopt: Towards end- 
user segments. Focus will point the firm in the right direction, but a policy of continual 
improvement and organizational learning will be needed to achieve the aims. The 
suggestion we propose is to evolve into a product’s company by gradual acquisition of 
knowledge and reuse. 

Over time learn the intncacies of the chosen segment, understand the segment, its 
clients. It’s business needs etc. Specialize people in terms of the end-user or application 
domains. So that they acquire the knowledge of the sector. Through a continual 
process of knowledge acquisition, the firm can have evolved ways to meet the 
demands of the sector more efficiently, speedily and cheaper While the firm acquires 
domain level knowledge, it should also acquire the competencies in product 
development Ultimately, within the space of a few years, the firm should have evolved 
sufficiently in both dimensions to be able to develop its own products It should also 
have developed a market or “mind share’’ in the clients of that sector that should help 
to replace or cannibalize its service business by the product. The process is slightly 


elaborated below 



8.3 The Product Development Dimension 

“ Individual products are the offspring of product platforms that are 
enhanced over time. Product families and their successive platforms 
are themselves the applied result of a firm’s underlying core 
capabilities In well-managed firms, such core capabilites tend to be of 
much longer duration and brader scope than single product families or 
individual products The authors recommend a longer run focus on 
enhancing core capabilites, which includes identifying what they are 
and how they are applied and synthesized in new products” — Meyer & 
Utterback(1993) 

Our findings about the product companies imply that the following are some of the 
core competencies to be acquired for the successful development of products We call 
them core competencies, because these competencies, once acquired can be leveraged 
across several products or product lines A way to acquire them is to develop people 
by repeating the same tasks across several projects By giving these people training to 
improve their performance in their allocated tasks Over time, they should be expected 
to bring in improvements that they can impart to their fresher (younger?) colleagues. 

Requirements Generation. Being able to generate proper requirements is crucial to 
the software products business From our findings, it appears that domain experience is 
the crux to generating the initial requirements That would be the reason why all the 
product companies seemed to need domain specialists They gather the information 
and then have to produce them in a form that is taken as the specifications for the 


developers 



Just generating the requirements once is not sufficient The requirements change 
with time and increasing user sophistication. Thus a feedback mechanism also is a 
must that allows the requirements to be updated based on customer feedback. This 
insures that the product gives what the customers really need. 

Thus by repetitively doing projects in the same domain, specific people can acquire 
the understanding of the domain and translate them into suitable requirements The 
projects that the firm does can serve as the feedback process by which the 
requirements and domain knowledge can be increased 

Testing Product testing by a dedicated, specialized, independent group has been a 
common trait of the product firms seen This is another critical necessity This group is 
to ensure the quality control of the final product. All the product companies have 
portrayed a specialized testing group that is stable and devoted to testing only Our 
findings seem to imply that expertise m testing is a necessity for product companies 

By establishing a stable testing team, that tests the software for each 
project, we can use each project as means of improving our testing 
techniques for the particular domain And through suitable generalizations, 
we can evolve generalized testing knowledge 

Customer support services. These people have to deal with the customers. They will 
be involved in installing the software, providing user training, answering quenes, 
solving difficulties etc These people also happen to be the source through which the 
feedback gets channeled into the development group Thus the customer support 
people must be supported with systems that allow them to record complaints. 



suggestions etc that then are available for the requirements, development and testing 
people. 


By specifically setting aside particular people to do customer installations 
of the project software, we can develop the rudiments of support skills. 

There is another trait that we think should have been m this list is Documentation . A 
software product is not just the software itself, but also the documentation that goes 
with It that describes how it works, how to use it, etc This documentation could be m 
the form of on-line help or through the hard-copy manuals We noticed only one 
company in our study that had a dedicated group for documentation 

We should set aside the documentation task to be done by the same set of 
people across projects. This will help in evolving standards of 
documentation and also develop skills in proper documentation 

All these are acquirable over a due course of time. The change from services to 
products cannot be sudden We propose that it is possible by following the service 
concepts to evolve into a products based company Central to the scheme is a continual 
improvement and learning orientation Individual projects are used to achieve 
organizational learning (See Basili and Calidera, 1995, who use the philosophy to 
improve the software quality, and a good method to go about it ) We do not give 
solutions for marketing the product Though as we stated above, the goal is to offer 
the customer this product instead of offering to custom-build the software for him The 
idea IS to cannibalize the current service business by offering a product that is cheaper, 
more reliable and quicker to go into operation. The product replaces the service 



How to achieve focus, we propose that the service companies should first focus their 
business according to the application domains “A domain defines a common problem 
space whose solutions share design decisions It often represents an industnal area, 
such as telecommunications, medicine, defense, process control, and so on ” (Olsen, 
1994) 


This can be done by limiting kind of projects taken by the company to those 
in the desired domain That is the company develops an expertise m 
consistently doing projects of that kind Each project serves to increase the 
knowledge base of the company By storing and analyzing it’s project 
experiences it can add to the organizational and individual learning It thus 
builds a manpower base that is familiar with the domain and its solutions. In 
time, the company will have acquired enough requirements to analyze and 
identify the sections that are invanant over clients These are then the 
pieces that can be replaced by reusable code The company could also 
adapt tools that speed up the development in this particular domain. In 
time, the company will have sufficient knowledge base to convert it’s reuse 
efforts into a complete product It can market this product to its 
prospective service customers. The clients must be convinced that the 
product will serve their needs faster (no development time from scratch), 
higher quality & more reliable (reused code would have already undergone 
so many tests), and cheaper 

This way, the company does not lose out on its current service business. 
Yet It IS engaged in a learning process that helps it to acquire the required 



competencies for full fledged products. The services business is used as the 
feedback process observed in the product companies to incrementally 
improve our understanding of the domain and develop our competencies 
(See Macala et al , 1996 . They explain how to manage domain specific 
product development They descnbe their organization to carry this out.) 

While the above process is going on, the company should have set in place systems to 
acquire the above mentioned core competencies It should hire domain experts to 
become part of the project staff, allocate people so that they can specialize m testing, 
e g let people specialize in onsite installation so that later on they can be full fledged 
customer support personnel Instead of having the project team members do all the 
tasks, let these specialists handle the tasks that they develop expertise in Let there 
arise experts in documentation, testing, requirements, support service etc Let these 
figure out how to do their tasks better. 

This will also require a change in the training patterns for the fresh recruits 
or for those allocated to this kind of a setup. These people will have to be 
trained in the tools that the project is using for its industry and also training 
on the reused components and how to use them 


8.4 Limitations Of the Study 

The methodology of the study . The data has been collected by interviewing people, 
discussions with them, reports of discussions etc. Their interpretations and biases 
affects the data provided by them. Occasionally, it was felt that the subject was 
attempting to say what the investigator would have liked to hear, and not what was 



factual. It has not been possible to interview every corresponding person across the 
companies This industry shows a lot of mobility and sometimes the ideal candidate 
was unavailable. In some cases, there have been gaps in some information available 
from one company Thus some observations have not been presented due to lack of 
corresponding data from the other similar companies. It has not been possible to 
validate information given by one person through questioning the colleagues on the 
same points The colleagues demurred from even casually commenting on topics that 
they thought they are not competent to answer Since only one investigator was 
involved, not all the information discussed was recorded 

The type of organizations studied All the service type organizations studied are export 
onented It would have greatly improved the robustness of the generalizations if we 
could have got domestic service providers as well. A large number of foreign 
companies are setting up their software businesses here Most of the companies studied 
here are Indian companies. One of the companies studied which has a component of 
foreign ownership showed some differences in organization in comparison with the 
Indian owned enterprises. It would seem possible that the influence of the foreign 
ownership could affect the organizations in such companies. Thus the generalization of 
the observations here are poorer for unavailability of that kind of data 

The scope of the study The study does not look in detail into the functioning of the 
other departments like finance, administration etc So differences in these departments 
cannot be commented upon Linutations of time on the part of the subjects & 
investigator prevented lengthy in depth discussions There are some topics which have 
not been covered in sufficient depth due to these restrictions 



8.5 Strengths of the Study 

Our confidence in our findings are improved by some literature that we came across 
veiy late m to the thesis Some of the confidence emerges from the data set we 
encountered. 

The spread of the cases We have been very fortunate in having an equal spread of 
compose for each type and even more to have one sample that is involved in both — 
service and products The clear distinctions in the internal operations for the 2 kind of 
outputs of the company adds strength to the generalization The product companies 
are into different segments and yet show common traits The sizes of the companies 
vary but the common traits are well exhibited by all Another fact that lends to the 
robustness of the study is that all the companies studied are in different cities in India 
Local effects are thus discounted. 

External support for the findings We have an unexpected support of our findings in a 
recent released book This could even be taken as another case study for our research, 
done by an independent author 

Product findings The findings of Michael Cusumano (1996) in his very recently 
released book “Microsoft Secrets”, support our findings for the product 
companies He finds Microsoft to have a IT ratio of developers to testers. The 
testers are an independent lot from the developers The requirement’s generation 
function has a separate group allocated to it And Microsoft has institutionalized a 
feedback process from its vast customer support divisions The feature of product 
training is carried out by the group called “User education” that also does the 
documentation for the products The corporate organization of Microsoft is based 



around product lines and products Microsoft follows Yoffie’s observations that 
the managers should be technically competent. Most of their product managers 
have nsen from the developmental groups or have had considerable expenence 
elsewhere. From the support of the findings of this book, and our findings, it 
becomes very clear that competencies in testing, requirements generation and 
feedback channels are a must for product development. 

8.6 Future Work and Extensions 

Effect of ownership on the structure of the companies The discrepancy of the 
corporate structure of one of the companies raises the point of the effect of the 
ownership on the organization of software companies. Since a number of foreign 
companies are opening Indian operations for software, it seems to be pertinent to see 
what differences exist in the Human Resource Management practices and structures in 
the Indian owned and foreign owned firms 

Software engineering models & the organization • Almost all the companies studied 
seemed to be following the waterfall model of software engineenng. One of the 
product companies was planning to go into object reuse in a big way Dunng 
discussions with the manager of this initiative, he mentioned that with object reuse, the 
whole development process and organization will change. If they carry out the reuse to 
the extent he foresees, then he expected to hire only domain experts or MBA’s in the 
domain to patch together the final application program from the set of reusable 
components According to the manager, the sizes of the application development teams 
could be drastically reduced The effort of development would instead be focused on 
the development of the reusable components Given that object reuse is expected to 



become an accepted way of software development, it seems pertinent to ask how will 
the management practices and organization have to change to accommodate this 
change in the technology of the organization. In short, research in detail the relation of 
technology and the software organization How will an organization look if it uses 
other models like the spiral or Rapid Application Developmenf^ 

Learning paradigms and software organizations During the study, one of the most 
staking feature noticeable across the industry seems the heavy amounts of training 
continuously going on Keeping up with the technology is a strategic necessity for 
organization and individual alike Given the fact that the technology of the machines, 
the software technology change rapidly in this business and customer’s expectations 
also change, adopting a learning organization seems to be an answer to constant need 
to update knowledge Modeling a software organization as a knowledge intensive firm 
(Starbuck, 1992) seems to be an alternative to a service model. Our suggestions for an 
evolutionary approach to products relies heavily on organizational learning It seems to 
be logical to pursue this stream of research next to find how to reorganize a service 
firm for maximum speedy effective learning 

Quality Systems and the Organization: Quality systems and software development are 
very closely linked The effect of ISO certification on the software firms organizations 
needs to be explored It may have led to a bureaucratization of software development. 
And It could be the reason for a finding similar organizations in the service firms. 
Following the Capability Maturity Model (CMM) model of the Software Engg. 
Institute, Camegie-Mellon University, eventually leads to a learning organization The 
Software Engg Laboratory of NASA proposes a model based on continuos 
improvement. This model too seems to advocate moving towards a learning based 



organization Thus it is the quality systems that demand organizational changes The 
link between these needs to be better explored. 


We briefly recapitulate Yoffie’s observations about the IT industry He mentions 5 
charactenstics: 

• Global nature 

• Blurring boundanes 

• Alliances 

• The Phenomenon of Lock-m & Lock-out . T‘ mover advantages, breaking 
new grounds, cannibalizing your own business 

• Need for technically literate managers 

In view of the above points we have the following observations' 

• The Indian software service companies are managed by technically 
competent managers 

• In the world software market, we certainly have some L' mover advantages 
for our software capabilities These should be exploited to keep ahead of 
our other competitors From a services viewpoint, we have a track record 
that generates trust in the clients. 

• Some companies such as SI are going in for long term alliances with their 
clients They thus have locked-in their clients and are m a position to deeply 
understand the workings of the client, and have little effort to make in 
establishing rapport with the clients. 



Our software companies have made their success in the services segments. If we 
believe in Yoffie, that cannibalization of the current business is a necessity in the IT 
industry, than it is about time that our companies found out ways to cannibalize the 
business from the way it currently is done. Before some other country does for us. 

9. Appendix 

9. 1 Appendix 1 

On the Strategic Management of Information Technology 

This appendix carries excerpts from Yoffie. In particular the explanation of the major 
themes common to the IT industry. The software industry is a subset of the IT industry 
and thus these themes recur in dealings with the software industry 

Yoffie identifies the major themes that cut across the IT industry Some excerpts 
follow These help us gam an insight into the working of this high tech industry 

1 Global geographic scope Yoffie terms this as the most obvious feature 
shared by all infotech industries All the industries share a common set of 
customer requirements that behooves any competitor to expand beyond 
their own territory Also, in some mdustnes like semiconductors and 
telcom, R&D costs and scale economies make it an absolute necessity. 

2 Blumng industry boundaries - "technology has blurred the boundaries 
between the industries and across industry segments” (His italics) Earlier 
the giants like IBM, DEC & other vertically integrated firms dominated the 
industry. The competition was across all segments In the 1990s, however, 
these are disintegrating while, independent vendors like Intel in hardware. 



Microsoft in software, and Compaq, Dell, & Apple in personal computers 
are vying for market share within their honzontal. This blurring of 
mdustnes is apparent in the way the telcom and the content software 
companies have been merging This is expected to continue well towards 
the end of the decade, only get more intertwined 

3 Blurring firm boundaries - The blumng of industry boundanes has been 
accompanied by a blurring of firm boundanes Alliances are everywhere, 
particularly across national borders (e g Apple Inc And Toshiba/Sharp for 
their Newton Pad) The motivations have ranged from alliances with the 
govt ; alliances on ‘pre-competitive’ technologies within an industry; nsk 
shanng alliances among firms Examples are the PowerPC combine, the 
OSF (Open Software Foundation, a consortium of UNIX companies), etc. 

4 Lock-in & lock out effects - High technology industries suffer from or 
benefit from “lock-in” & “lock-out” effects Lock-in effects means that 
once firms make a commitment down a particular path, it becomes 
increasingly difficult to change direction For both suppliers of technology 
and consumers of products, infotech exhibits extraordinary switching costs 
The obvious reason. IT tends to have broad applications within a 
customer’s business. The same scenario emerges in the PC market Both 
Microsoft and Intel have locked-in the majonty of computer users because, 
so much time, money and energy have been spent on buying X86-based 
hardware , training corporate personnel on DOS-Wmdows software Few 
customers are eager to switch Locked-out would occur if a firm is not part 



of a standard, it is excluded from participating in the growth and profits 
available to the Intel’s’ and Microsoft’s’ who locbn their customers. 


There are several cntical implications of lock-in and lock-out effects The most 
important is the rule of first mover advantages The T' to establish a standard, the to 
move down steep learning curves, the first to build economies of scale in segments 
where lockin effects exist usually reap the lion’s share of the profits Though is no 
guarantee of success And first mover does not necessanly mean being the very first to 
market. Though Apple created the market for standalone PCs”, it was IBM, 5 years 
later that recognized its potential and created the standard It seems creating a standard 
IS to get as many to support your invention as possible Like SUN’s Java 

The 2"'* implication of lock-m and lockout is recognizing that breaking new ground in 
an industry like IT requires a return to the old adage try, try and try again. Because of 
lockin, any change is difficult to engineer. Companies willing to make big bets on 
innovation can make it happen E g Microsoft failed repeatedly to introduce its 
Windows GUI, before it succeeded, spectacularly 

The implication of lock-in & lock-out, is the willingness to cannibalize your 
business Perhaps the most difficult strategic move for any firm in any industry is to 
offer product or services, which reduce the sales of existing product lines The history 
of IT provides very clear lessons on this pint If you have the capability to canmbalize 
your own product hues, and choose not to, someone else surely will The danger of 
refusing to cannibalize your own sales is that when new products or technologies 
emeroe as substitutes, they get locked m, and you get locked-out The strategic 



question of cannibalization is not one of ‘if, it is only a question of when. Whenever 
technology makes it possible, other firms always find a way to utilize it 

1 Mastenng technology - The fifth theme is that managing FT businesses 
defies some of the standard wisdom of general management. Just being a 
good general manager may not be enough for IT firms; excellent managers 
IT firms are invariably those who can mctsisr tschnology The resource 
allocation requires an in-depth understanding of technological trade-off. As 
a consequence, financially-dnven or marketmg-onented general managers, 
without a strong understanding of the technological frontier, usually have 
severe problems in trying to steer the course of an infotech business. The 
most celebrated example of this is John Sculley, of Apple He joined from 
Pepsi, with a reputation of good operating skills and marketing savvy 
Repeatedly Sculley found that he could not push Apple in the directions he 
believed to be the future, he was besieged by engineers with all of the 
technological problems It was not until Sculley appointed himself Chief 
Technological Officer and committed himself to learning the technology 
that he as m a position to steer the company as a leader and general manger 
should Microsoft’s Bill Gates, effectiveness as a leader and a manger 
stemmed fro his ability to allocate effectively corporate resources and his 
own time to highly valued projects that had the highest potential payoffs. 
Although IBM spent more on R&D than most of the computer industry 
combined, many of their problems m the late 1980s’ and early ‘90s’ 
stemmed from their difficulty in turning R&D dollars into hit products. 



The are few industries which match the rapid pace of change and the numerous nsks 
and opportunities offered by the new information technologies. Sinularly, there are few 
industries that require such constant renewal and organizational transformation. 



9.2 Appendix 2 

9.2.1 What is different about software 

This appendix has 3 parts to it. The first part excerpts Brooks (Brooks, 1975) 
statements ( with some extra matenal by me) on what is programming all about. The 
other part is part of a debate over the USENET, in the comp software-eng 
newsgroup on the nature of software. The third part details some notes about software 
engmeering 

9.2.2 The Craft, its Woes and its Joys. 

What IS being produced by either large industrial programming teams or garage duos‘> 
Brooks categorizes software efforts into 4 types He explains with a diagram (See 
Figure 9-1) The 4 categories are a program, a programming product, a programming 
system and the programming systems product Each type involves different levels of 
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A program, on the upper left quadrant of the diagram, is complete in itself. It is ready 
to be run by the author on the system on which it was developed. This most commonly 
exemplified by the class assignments that students do or the internally developed & 
used programs of a department. There are two ways a program can be converted into 
a more useful, but more costly, object These 2 ways are represented by the boundanes 
in the diagram. 

Moving down across the horizontal boundary, a program becomes a programming 
product This is a program that can be run, tested, repaired, and extended by anybody 
It IS usable in many operating environments, for many sets of data. To become a 
generally useable programming product, a program must be written in a generalized 
fashion In particular, the range and form of inputs must be generalized as much as the 
basic algorithm will reasonably allow Then the program must be thoroughly tested, so 
that It can be depended upon This means that a substantial bank of test cases, 
exploring the input range and probing its boundanes, must be prepared, run and 
recorded Finally, promotion of a program to a programming product requires its 
thorough documentation, so that anyone may use it, fix it, and extend it As a mle of 
thumb, he estimates that a programming product costs at least three times as much as 
debugged program with the same function An smaller scale example would be 
Wordstar, or Lotus 123, when they first came out They never became available on 
other systems, but had documentation, were tested, etc A fine example are the GNU 
products like gcc-a compiler, perl etc that are well documented, run across various 
platforms. Being public domain, it is extended, fixed by many people across the world. 



everyday. These kinds of systems are the children of the Internet Any extensions 
made, that are found to be useful are incorporated into the next version No matter 
who made it 

Moving across the vertical boundary, a program becomes a component in a 
programming system This is a collection of interacting programs, coordinated m 
function and disciplined in format, so that the assemblage constitutes an entire facility 
for large tasks. To become a programming system component, a program must be 
written so that every input and output conforms in syntax and semantics with precisely 
defined interfaces The program must also be designed that is uses only a prescnbed 
budget of resources— memory space, 10 devices, computer time Finally, the program 
must be tested with other system components in all expected combinations. This 
testing must be extensive, for the number of cases grows in a combinatorial fashion. It 
is time-consuming, for subtle bugs arise from unexpected interactions of debugged 
components A programming system component costs at least 3 times as much as a 
stand alone program of the same function The cost may be greater if the system has 
many components This can be exemplified by the office suite of programs that are 
available e g MS Office, SmartSuite which has Lotus 123 type spreadsheet as just one 
component of the suite of programs like a database manager, a wordprocessor, etc 
The data developed with one of these is components is effortlessly incorporated as 
data of the other component 

In the lower right hand comer of the figure, stand the programming systems product 
This differs from the simple program in all the above ways It is generalized, it 
undergoes testing, has documentation, is maintainable, is integrated or intergrateable 



through Its well-defined interfaces. It costs 9 times as much. But is the truly useful 
object, the intended product of most system programming efforts. 

After explaimng what is it that is made, in rather poetic fashion. Brooks goes on to 
explain why programming is fun. Later, he goes on to explain why its so much 
headache. 

1 For the sheerjoy making things Especially things of own design. 

2. For the pleasure of making things that are useful “Deep within, we want others 
to use our work and to find it helpful ” 

3 Third is the fascination of fashioning complex objects of interlocking moving 
parts, and watching them work in subtle cycle, playing out the consequences of 
pnnciples built in from the beginning 

4 The joy of always learning, which spnngs from the non repeating nature of the 
task In one way the problem is ever new, and its solver learns something, 
sometimes practical, sometimes theoretical, and sometimes both. 

5 There is the delight of working in such a tractable medium The programmer, 
like the poet, works only slightly removed from pure thought-stuff. He builds 
his castles in the air, from air, creating by exertion of the imagination. Few 
media of creation are so flexible, so easy to polish and rework, so readily 
capable of realizing grand conceptual structures This tractability has its own 
problems. Yet the program, unlike the poet’s words, is real in the sense that it 
moves and works machines, controls airplanes, satellites, transfers money 

between banks etc. 
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His explanation highlights the non repeatable nature of the task, and the tractability of 
the medium He then explains what makes software such a headache. 

1 One must perform perfectly Human beings are not accustomed to being 
perfect, and few areas of human activity demand it 

2 Other people set one’s objectives, provide one’s resources, and furnish one’s 
information. One rarely controls the circumstance of his work, or even its goal 
In management terms, one’s authority is not sufficient for his responsibility 
The programmer depends upon other people’s programs These are often 
maldesigned, poorly implemented, incompletely delivered and poorly 
documented So he must spend hours studying and fixing things that m an ideal 
world would be complete, available and usable. 

3 Designing grand concepts is fun, finding nitty little bugs is just work. One finds 
that debugging has a linear convergence, or worse, where one somehow 
expects a quadratic sort of approach to the end. So design drags on and on, the 
last difficult bugs taking more time to find than the first 

4 The last straw is that the product over which one has labored so long appears 
to be obsolete upon (or before) completion Already colleagues and 
competitors are in hot pursuit of new and better ideas. Already the 
displacement of one’s thought child is not only conceived, but scheduled Of 
course, the technological base on which one builds is always advancing. As 
soon as one freezes a design it becomes obsolete in terms of its concepts But 
j^plgfTientation of real products demands phasing and quantizing. The 
obsolescence of an implementation must be measured against other existing 



implementations, not against unrealized concepts. The challenge and the 
mission are to find real solutions to real problems on actual schedules with 
available resources 


9.2.3 USENET Debate 

These excerpts from a USENET debate on the difference of software is included to 
give an idea of the issues involved, the differences and some of the thoughts of 
practicing software engineers Most of the important information from the headers is 
given for completeness Any or the complete debate can be retrieved by searching 
with the subject header from any of USENET archives like Dejanews, Yahoo or 
Altavista on the world wide web 


Subject: Re: What’s different about software? 


1 From: patnck_d_logan@ccinjf Intel com (Patrick D Logan) 

Newsgroups comp software-eng 
Date Tue, 22 Nov 1994 15-33 03 
Organization Intel / ProShare 

Dikstra (sp'^ apologies) made this analogy many years ago. 

(Paraphrasing) 

The electronics designers essentially take the same design and apply different technolgies to 
It over and over The software designers essentially take the same technology and apply it to 
different designs over and over 
(End) 

Now that is an oversimplification, but a very useful one to begin to understand the 
fundamental differences between software development and other engineering disciplines. 
Patrick_D_Logan@ccmjf intel com 
Intel ProShare Teleconferencing 
(503) 264-9309 FAX (503) 263-3375 


2. From: tkarp@pipeline com (Tony Karp) 

Date 24 Nov 1994 17 01 04 -0500 

Organization TLC Systems Corp ... 

It can only be fixed by the manufacturer This is truer for software than for most other products 

If your TV or VCR or car breaks, you can probably get it fixed locally 
Not so with software If MS Word is broken only Microsoft can ix it 
Software doesn’t wear out — it becomes obsolete 
Tony Karp, TLC Systems Corp, NYC — tkarp@ pipeline com 
3 From: gnffmd@sunny dab ge com (David W Gnffin) 

Date 28 Nov 1994 12 25 19 GMT 


S^ftw^rrisTasiesTto'c^^ae, but not easiest to change correctly Ask the electncal engineer how he 

ttTdTlce .0 build . compWr motherboard p.e„thal he has to fabneate tdl hts own 

V, H iiQincr hic own Silicon foundary and only the minimum automation Ask him how he d like to 



solder That s what we have to do all the time There are no available, accessible, reliable catalogs of 
software components for the average software developer 

As for tools, at the EE has his oscilliscopes and meters and analysis tools What does a software 
developer have'^ Usually just a compiler, linker, andif he^s extremely lucky, a debugger (and if he’s 
*really* lucky it might bea source level debugger) 


David W Griffin I Martin Manetta Corp 

gnffind@escmail orl mmc com I Orlando, Florida 
(407)826-3697 I Posts are my opinions only 


4 From: tkarp ©pipeline com (Tony Karp) 
Date 28 Nov 1994 18 29 58 -0500 
Organization TLC Systems Corp 
Lines 24 


Another way that software is different from 

Software is more subject to catastrophic failure than most other things While other things may fail 
catastrophically, it is far more common in software 

There are many ways that software is different I think that it important to try and recognize these 
differences and gain some understanding from them 
It’s about understanding what we do 

The real question is what would you do if your car misbehaved as often as your computer'? 

Tony Karp, TLC Systems Coqp, NYC — tkarp ©pipeline com 

5 From: serviss@tazdevil cig mot com (Gerald Serviss) 

Date 29 Nov 1994 00 05 54 GMT 

Organization Cellular Infrastructure Group, Motorola 
Lines 65 

Software development as a job descriptionis at best 50 years old Considering that electrical 
engineering is perhaps 100 years old, we are young and very young compared to say bridge building. 
Yes, this is true but we would be strained to be like say an auto maker offering tons of options and 
colors on those million shipped units The software that you are taking about is relatively simple as 
compared to the most complex stuff (telephony systems, air traffic control 
etc) 

The issue that is being missed here is that the large software projects that are undertaken today are the 
most complex ‘machines’ ever built by humankind Would you have felt safe with your code orbiting 
the planetand controlling weapons of mass destruction ^ I don’t think that I would have 

Democracy is where you can say what you think even 1 Jerry Serviss 
if you don’t think I Motorola Inc 

I serviss @cig mot com 

6 From: roger_ml @hnlv4 verifone com 
Date. Tue, 29 Nov 94 03 49 44 GMT 
Distribution world 

Organization VeriFoneInc 
Lines 44 


Guy A Lyle wntes 
> 

>Please consider the relative youthfulness of the software engineenng 
>”profession” compared to that of electrical or mechanical engineering 
>We are “not very good” because our branch of engineenng has yet to 
>estabhsh reliable, repeatable processes. i 

Which in turn, is because we don’t yet have mature technology Bytechnology I don t mean tools and 
design’methods, I mean an establishedbody of knowledge about the nght way to build things. Given 
the needto design a veebleflexor, most engineers can go to handbooks, etc andfind out how 
veebleflexors are built He will choose among variouswell-understood alternatives for the veebleflexor 



subsystems And hewill probably add a little bit of creative innovation to make this onejust nght for 
his particular customer 

But a software engineer designing, oh let’s say, an airport baggagehandlmg system, typically starts 
out with a blank sheet of paper and thehope that the lack of solid application knowledge can be 
compensated forby pure methodology I view the CMM as basically an attempt to force th^eoutward 
trappings of a mature process onto an immature technology Thismay not be a bad thing to do while 
waiting for the technology to evolve, but I am very skeptical that truly fundamental improvement will 
come fromthis path 

As an exception which proves the rule consider compiler design Here thereis a well-established body 
of theory and practice, and in my expenencecompiler projects generally go pretty smoothly and 
produce reladvelytrouble-free products compared to other software of comparable size andcomplexity. 
As far back as “The Mythical Man-Month” Fred Brooks observedthat “The flaws in design and 
execution pervade expecially the controlprograms, as distinguished from the language compilers ” 
Also, “Some ofthe compiler teams in the OS/360 effort were building their third or fourthsystems, and 
the excellence of their products shows it ” 

Roger Miller VenFone, Inc roger_ml ©verifone com 

7 From: tej ©world std com (Thomas E Janzen) 

Summary There will never be a “s/w design made easy” video 
Keywords software, design 

Organization The World Public Access UNIX, Brookline, MA 
Date Wed, 30 Nov 1994 01 43 25 GMT 
Lines 27 

There will never be a textbook on building software systems for baggage handling systems I would 
be surprised to find a textbook on building baggage handling hardware Software is being applied to 
so many new and innovative applications every day that they vanety of applications is indefinitely 
large Principles can be discovered and invented, thus real-time studies, compiler technology, 
numerical analysis But the increasing vanety will continue to grow 

This IS why it is important to have domain experts and software experts who can communicate during 
requirements analysis Domain experts are the worst coders in the world (unless the domain is CASE, 
or even then) But they are needed to define products 

And yet,scientific companies who need first- or second-rate s/w engineers hire 2"‘‘-rate scientists (4-th 
rate s/w developers) to write software in the belief that scientific knowledge is more important than 
s/w knowledge when writing real-time code 

A complete requirements analysis embodies the domain knowledge required for the project (but of 
course training in the domain helps the developers) 

Denver of course had management problems and last-minute changes from a johnny-come-lately but 
key customer 

The Therac-25 had a h/w problem they removed the h/w interlocks 

Tom Janzen - tej@ world std com USA Distributed Real-Time Data Acquisition S/W 
for Scientists and Engineers using *nix, C, C++, X, Motif, Graphics, Audio 
See my video Dilettante at the DeCordova near Boston to December 7 94 

8 From: John_R _Goold@magic ca (John R Goold) 

Reply-To John_R _Goold ©magic ca 
Date 02 Dec 1994 00 54 15 GMT 
Organization Magic Online Services Toronto Inc. 

Lines 32 

In <CzMI8E GEA©harlequin co uk> daveb@harlqn co uk (Dave Berry) wntes 

» 


>Larry Dick writes ^ . 

>It seLs to me that when multiple disciplines interact with software, 

>then decisions are made (sometimes on the fly) that force software to 
>pick up the pieces for hardware problems Even at system design, trade 


>offs are made that add to the detail and complexity of software. 

> 

>When was the last time a hardware designer offered to add a few IC’s to 
>the board to mitigate a software problem unless the software was shown 
>to be unable to perform without added hardware? 

> 

>Yet, this IS how it should be, software is the easiest environment to 
>make a change in It is usually easier to modify software than hardware 
>(mechamcal or electncal) It is usually easier to develop control 
>logic in software than in hardware, etc And finally, it is usually 
>easier to ship software than hardware 

>But, the cost of all of this is that the software becomes more and more complex while at the same 
time the hardware environment is stripped of all the complexity that can be reasonably disposed of I 
agree, in essence, with what you say, but it is a mistake to make this a rule of thumb (i e don’t change 
the hardware, change the software) Anyone disagreeing should read the report on the Therac-25 



9.3 Appendix 3 

This appendix is a secondary reading for the chapter 3 This gives detailed information 
on the definitions of services and issues within services management. Following the 
services note are notes on the software product concept 

9.3.1 On Services as opposed to Goods/Products 

This definition and the issues etc Related to services is excerpted from Bowen et al 
(Bowen et al, 1990) 

A service can be viewed as “a contract under which one or more persons (principals) 
engage another person (the agent) to perform some service on their behalf which 
involves delegating some decision making authority to the agent” Marx wrote “ 
Services are consumed the moment that they are produced The useful effect can be 
consumed only during the process of production It does not exist as a utility different 
from the process, a use-thing which does not function as an article of commerce, does 
not circulate as a commodity after it has been produced ” (Italics mine) Bell (Bell, 
1973) describes work in an industrial society as pnmanly a “game against fabncated 
nature ” In contrast, he describe work in the postindustnal services-dominated world 
as primarily a “game between persons”. 

The commonly agreed upon attributes of services are as follows (Bowen et al, 1990); 

1 Services are intangible Services are expenences that are rendered, while 
products are objects that are possessed Intangibility makes it difficult for 
management, employees, and customers to assess service output and service 
quality. 



2. Services tend to be consumed and produced simultaneously. This simultaneity 
complicates the process of managing the supply of & demand for services. The 
customer-contact personnel cany out management, operations and marketing 
functions as they do their jobs Particularly in labor intensive services, quality is 
created during the service encounter between service provider and customer 

3 Customer Participation customers tend to participate in the production and 
delivery of the services as they consume Customers provide the information 
that is the raw matenal to be transformed to service output Services also 
depend on making use of the clients efforts in the transformation process. 

Though the above attributes ( intangibility, simultaneity of consumption & production, 
& customer participation), are taken as the general features of services; there is no 
strong consensus regarding the precise distinctions of services & goods Clear 
delineation is difficult, if not impossible, given that output of goods is typically 
accompanied by a facilitating service and service output is sometimes accompanied by 
a facilitating good But clear delineation is not the goal The purpose of specifying 
attributes of services is to offer a conceptual map for locating where good and services 
differ. 

9.3.2 Issues in service management 

Services have unique strategic issues This is because of their intangibility Customers 
must commit to purchasing before service production, and the services themselves are 
to a large extent ephemeral, making the evaluation process primarily subjective and 
customer dependent. Because of the intimate relationship between perception, 
evaluation and the experience, the roles of production and marketing are inextricably 



intertwined for employees just as human resource management and internal marketing 
are for supervisors The service outputs are difficult to separate into units, so 
measurement too is difficult, adding to the already intertwined, fuzzy production 
process 

Given the intangible nature of service, & its production process, there is little 
assurance that the quality of the service will be the same from time to time The end 
result needs to be a service production process that is consistent over time, place, 
employee, customer service product. Intangibility means that clients often have few 
objective reference points to use in perceiving the value of the service they consume. 
Relevant cues are ambiguous, and client perceptions are highly subject to social 
influences Thus there is incentive for the service operations to make relations with 
service providers more satisfying to the clients, e.g , the friendliness of the bank teller 
or the telephone operator is an important factor in customer satisfaction. ‘Climate’ is 
evidenced not only by employees’ actions but by other, more physical factors Such as 
furniture arrangement, use of space, physical appearance of servers (& customers!) 
impinge on the server-customer relationship All this is part of the ‘atmospherics’ of 
the service encounter that clients use to evaluate the service Since the service is 
intangible, these more physical and perceivable factors take importance. 

Simultaneity of production & consumption leads to the game between persons It is 
when the customer orders, that the production begins, and also the consumption This 
implies that the producer and the customer must interact for the delivery of the service 
to be complete In some senses, the producers are mini-factones unto themselves, 
because they not only produce the output but also sell it. This complicates things. The 



customer has to be brought into the production process. And the customer is not a 
controllable entity like iron and bnngs m an uncertainty into the production process 
that cannot be organizationally isolated Couple to this the fact that the customer is 
uncertain of the quality of the service provider. The customer looks for signs of 
competency in the provider, the provider seeks to control the customer’s reactivity. 

The customer is ego-mvolved in the process, since it is they or their personal property 
that that constitutes the raw matenal transformed, and yet another reason for their 
apprehensions. Thus the provider has to provide the rationale or explanation for the 
actions actually take by the service provider. This is a form of technical justification 
that IS undertaken solely by the service provider. Technical justification is a bonding 
mechanism to assure customers of the service provider’s competence under conditions 
of uncertainty. This is causal information for a decision and is also instrumental in 
clients’ receptivity to the service being rendered The more reactivity expected from 
the client, the more technological justification can be correspondingly expected of the 
service provider. 

It IS the customers’ involvement in service operations that generates the notion of 
“technical” relationships — a series of indispensable changes in the technology. This is a 
segment of service technology that is embodied in the social interaction between 
service providers and clients Within such interactions, information is generated, 
converted, and exchanged in the process of rendering the service to clients The task 
activities necessary to convert the informaUon in the transaction will depend largely on 
the bnds of relationships that exist between provider and customer-client. 



Consequently, the technology of the service becomes inseparable from the social 
relationship between provider and customer. 

Thus the high customer contact employee, is involved in a three-way interaction 
between themselves, customers, and the production process or technology The 
workers in jobs, dealing with only matenals or things and not with people are required 
to be technically proficient only The high contact worker must manage the customer- 
technology interaction. He must also simultaneously interact directly with customers. 
These 2 additional interactions he at the heart of the game between persons, posited by 
Bell Thus the cohesion between servers and customers can influence the productivity 
of the service organization It is important to present to the customer, employees who 
are perceived as competent This perceived competence will serve to increase the 
employee’s credibility with the customers and will lead to an improved flow of 
information between the employee and the customer. This then will facilitate the 
production of the service 

The key raw material for the service production is information which must usually be 
obtained from the customer. Clearly, interpersonal skills are important here as they 
relate to the communications process involved in obtaining this Thus for optimal job 
performance neither technical skills nor interpersonal skills alone, are sufficient For 
example, we expect airline flight attendants to be technically competent concerning the 
safety and passenger service aspects of their jobs, but we also expect them to be 
mterpersonally pleasant, and attractive, as they instruct/train passengers in the use of 
safety equipment and provide in-flight service. 



9.3.3 Gunther’s Assumptions for Software Products 

A software product is a computer program plus all of the planning, documentation, 
testing, publications, training, distnbution, maintenance, and control that comprise the 
aggregate software product — software to be installed at more that one site, for use by 
people not known by the developers, in sways not anticipated by the developers. 

The assumptions Gunther maintains for software products are - 

1 The developer is unacquainted with the user. 

2 User requirements either are developed by the developer or are presented to him by 
an intermediary, such as a marketing support organization. 

3 Users do not participate in design reviews, except possibly when represented by an 
interaiediary 

4 The software must be run o a wide range of hardware configurations, in a wide 
range of software environments. 

5 Users install the software themselves or have someone other than the developer do 
It for them. 

6. Problems are resolved by correspondence, sometimes through an intermediary. 

These assumptions, he states are different from those commonly mentioned in books 
that are meant for programs, or software systems These other assumptions, that 
operate in these cases are as follows 

1 The developer is the user or is at least organizationally related to the user 



2 The user specifies his requirements directly to the developer. 

3 The user participates in design reviews. 

4 The software must run on only one or limited range of hardware configurations. 

5. The developer installs the software for the user 

6 Problems in using the software are resolved by direct interaction between the user 
and the developer/mamtainer 

A software products organization is markedly different from an open programming 
shop, where virtually all of the resources are concentrated in the development unit and 
are assigned on a rotational basis to client programming projects. 


Appendix 4 
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